My understanding is asp.net pages are grouped in folders and each folder is compiled into a dll file. However when a page is requested the first time, only that page is compiled? So is it possible to compile part of a dll file? And when a page is requested, is it only the page's code within the dll file is executed, but not the whole dll? Somehow I'm under thr impression that a dll file should be compiled or executed as a whole.
Your answer exists within ASP.NET Compilation Overview and the compilation element.
Directories are compiled when browsed to, but the batch=true/false configures if only the loaded page will be compiled, or all of the pages in that directory. (There's a maxBatchSize that configures maximum of pages to compile in a batch.)
Page can compile per folder if you have enable the batch=true. The compiler compile the first n page that found on the folder un-compiled.
Also compiles all the modules that need for the page that you run. When again found one other page that have not been compiled then again compile a second set of n files.
The limits of the how many files are compile with the batch=true, are set from the compilation settings .
If I understand well you search a way to seed up the developmental.
For your development computer I suggest 2 settings.
<compilation batch="false" optimizeCompilations="true" ... >
When batch=false then only the file you ask is called. When optimizeCompilations=true then the compiler did not build the functions on the dlls, nether some cache files if they have not change.
Read also: Slow Performance -- ASP .NET ASPNET_WP.EXE and CSC.EXE Running After Clicking Redirect Link
If you have problems with the compilations then set optimizeCompilations=false.
When the optimizeCompilations is on, there are case that the compile can not understand the change of a function and you get errors. One case is when you have a function call, and change the function by just adding an argument with a default value (net4). In this case the compiler did not compile it again, and this some times product errors.
However when a page is requested the first time, only that page is compiled?
If your application is a website,when it calls first time that aspx page compile automatically.But not for web application it will compile once when you build
So is it possible to compile part of a dll file?
Means you want to compile particular part of a project.
Related
Title asked it all,
Do dynamically compiled files, such as .cshtml files, use csc.exe in .NET?
I saw this question C# JIT compiling and .NET
But it doesn't fully go into the compilation of a dynamic file to before being Jit'ed.
So you have this site https://msdn.microsoft.com/en-us/library/ms366723.aspx.
Which says:
By default, ASP.NET Web pages and code files are compiled dynamically
when users first request a resource, such as an ASP.NET page (.aspx
file), from a Web site. After pages and code files have been compiled
the first time, the compiled resources are cached, so that subsequent
requests to the same page are extremely efficient.
So am I to understand that csc.exe runs on first request of a new resource before being JIT'ed?
The short answer appears to be yes.
Source: https://blogs.msdn.microsoft.com/webdev/2014/05/12/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications/
"the Roslyn compiler would be loaded into memory, improving greatly performance for not pre-compiled websites with multiple .asx/*.cshtml files. The new version, however, features a new /bin/roslyn/csc.exe file, which is executed once per file, completely removing the mentioned above optimization feature"
I am developing a piece of an existing web site and am having numerous issues trying to upload my files to the server. Everything runs fine locally, but once I put my files on the server things start breaking.
Right now I have a page that gets this error
"Parser Error Message: Could not load type '[Namespace].[PageName]'
. If I take out the inherits statement, it works. The namespace and the pagename are declared in the code behind, which is referenced in the page header.
I also just noticed that all of the pages that predate me don't have code behinds.
There are two options for putting a file on a web server.
One option is to compile it and use a "Publish" feature, in which all of your code-behind files are NOT on the server, and are instead are compiled down to the .dll.
Another is to not compile the site, and simply copy all the aspx ans .cs (or .vb) files out there, uncompiled.
Actually there are three, but I think you only need to deal with these two right now. They are described further at http://msdn.microsoft.com/en-us/library/ms178466(v=vs.100).aspx under the "Flexible Deployment" section.
Your predecessor apparently used the first method. The only way to fix this is to get the compiled .dll files out of the \bin directory, and decompile them using a tool like Reflector or Teleriks's Just Decompile. (The latter is free, the former has a free for a limited time trial period.)
Alternatively, if you can get the full source code, you can simply remove all the content already out ther and publish it using the non-compiled method. Of course, there will be down time, and you'll need to test pretty carefully...
When you have a codebehind file, it needs to get compiled into a DLL, and that DLL needs to be in the bin directory of the webserver. It doesn't actually work fine without the Inherits - nothing from your codebehind would be in there - it may only display ok initially, but none of the events would fire.
If the rest of the site is all done with the code included in the .aspx pages, then those pages are all standalone. But if you want to use codebehinds, then you'll need to publish the DLL.
Test easiest way to get your code up and running would be publishing the code. Inside of your project in Visual Studio right click on your application and click on publish then for the location you can just create a folder on your local system and select only files needed to run this application then select publish. It will only copy the files needed to run the application and you can copy those files to your server and everything should be correct. I will also copy your web.config/app.config file so make sure that everything is correct in that file or delete that file from the directory once the publish is done.
So I eventually talked to the lead developer for the other group that works on the site. He explained that they do a Solution Rebuild then just move any changed as*x files and the /bin .dll. For some reason, my subversion client didn't actually update anything when I asked it to update, so my branch didn't have some new controls the other group made. When I would build my solution it didn't include the .dlls for the new controls, so when I uploaded my dll the new controls weren't defined and I got the same message. When I took the new dll down, my controls weren't defined.
Anyway, I fixed that. Thanks for the answers.
I have faced a lot of issues with Publishing like when you need to make small changes on the code, sometimes the generated DLL file (the dll file for example of default.aspx.CS when published) cannot be recognized by IIS saying the codebehind is wrong or something. Sorry for not remembering the exact error message. I am hoping you know what I mean at this point.
Therefore, I usually do a simple Copy Paste operation instead of Publishing.
Could you tell me what am I missing by NOT using the Publish method? How is Publishing better? Or which one do you prefer, why?
Basically its a pros and cons situation.
Thankyou
Well, it depends on what you mean by "copy":
With Publishing you have options to pre-compile all or part of your application. You can publish to a local folder in your file system (instead of your target/host) and then copy the updated file(s) (only). If you are making "code behind" (c#/vb code) changes, this means you'll likely only need to "copy"/overwrite dlls. Goes without saying that if you've made "content" changes (html/razor/script/etc) changes, then you'd need to copy/overwrite those as well.
If you're new to deployment, you may find yourself simply copying/overwriting "everything" which is the safest way to go. Once you get more experience, you'll "recognize" which assets you only need to update (one or a few dlls and or content code, instead of "everything"). There's no magic to this, usually, its a matter of just looking at the timestamp of the dll/file after you've published (locally) or rebuild your web application.
I'd recommend doing a local publish so you can see what is actually needed on your server. The files published to your local file system/folder is what needs to be on your host/server. Doing so will visualize and remove whatever "mystery" there is to Publishing:
you'll see what is actually needed (on your server) vs. what's not
you'll see the file timesstamps which will help you recognize what files were actually changed vs those that weren't (and therefore don't need to be updated).
once you get the hang of it, you will not need to "copy"/ftp "everything" and just update files that were actually modified (only).
So "copy" can mean the above, or if you are saying you will simply copy all of your development code (raw (vb/cs)html/cs/vb) to your host, then that means your site will be dynamically compiled as each resource is needed/requested (nothing is pre-compiled). Also "easy" but you do lose pre-compilation which means there is a delay when each of your web pages are requested/needed (ASP.net needs to dynamically compile). Additionally, you are also exposing your source code on the server. It may not mean much depending on your situation, but it is one more thing to consider.
Here's more info on pre-compilation and options.
Assuming we consider an aspx page and its aspx.cs code behind file, there are three alternative ways of deploying your site:
You can copy both to iis. The aspx will be compiled to .cs upon the first request and then both .cses will be compiled to a temp .dll
You can "publish" to iis, this will compile the code behind class to .dll but will copy the aspx untouched. The aspx will be translated to .cs and then to .dll upon the first request
You can "publish" the site and then manually precompile it with the aspnet_compiler. Publishing will compile the code behind to .dll as previously but then precompilation will clear out your .aspx files by removing their content and moving the compiled code to yet another .dll.
All three models have their pros and cons.
First one is the easiest to update incrementally but in the same time is the most open to unwanted modifications.
Second is also easy, can be invoked from vs, it closes the possibility of some unwanted modifications at the server but .aspxses still need time to compile upon the first request
Third takes the time and some manual actions but prevents any changes and also speeds up the warm up of the site as the compilation of assets is not necessary. It is great for shared environments.
Just read about the possibility to use codefile=somefile.aspx.cs instead of codebehind=somefile.aspx.cs in web application projects (described here). Obviously this causes the file the compile only when loading the page, it's not precompiled anymore (right?).
Are there any negative or unexpected side-effects by using codefile instead of codebehind in a web application project?
I think you could run into problems for supportability if your site isn't all one or the other. (CodeFile or CodeBehind)
i.e. If you're trying to figure out a problem on your production site that your error handling tells you is within a certain file or namespace, you'll have to stop to examine every file and control that you are supporting before troubleshooting to see if the page is running as part of the compiled assembly or running from the codebehind on the site.
You could also run into conflicting or missing namespaces if you try to have a mixed environment.
Pros as I see it for CodeFile:
Your production source code can sit on your production website. If the code is all compiled in a DLL in your bin directory, there is no absolute guarantee that the code you have on your development environment or source control is what's out there. (Sure it SHOULD be, but if everything was always as it should be, many of us wouldn't have jobs fixing other people's code!)
For updates, you only have to push out single files, not an entire assembly.
You would be able to have developments in progress on other pages that you don't need to back out before recompiling and publishing to production.
Cons:
Since you're not pushing out a compiled assembly, you may have errors within individual files, that won't necessarily be caught unless someone visits each specific page or if you are sure to compile before deploying.
You may have conflicting namespaces in codefiles that may never be caught and could cause confusion or errors.
Performance issues for dynamic compilation
I'm using a deploy project to deploy my ASP.net web application.
When I build the deploy project, all the .compiled files are re-created.
Do I need to FTP them to the production web server?
If I do a small change do I need to copy all the web site again?
From my own research, the .compiled files must be copied to the production server, but not needed to copied every time
from Rick Strahl excellent blog:
The output from the merge utilitity
can combine all markup and CodeBeside
code into a single assembly, but you
will still end up with the .compiled
files which are required for ASP.NET
to associate the page requests with a
specific class contained in the
assembly. However, because the file
names generated are fixed you don’t
need to update these files unless you
add or remove pages. In effect this
means that in most situations you can
simply update the single assembly to
update your Web.
Source
You can get rid of the .compiled files by using the aspnet_merge tool with the -r option.
Removes the .compiled files for the main code assembly (code in the App_Code folder). Do not use this option if your application contains an explicit type reference to the main code assembly.
There's nothing special about .compiled files: it's just the actual file with a .compiled extension on the end so that nothing happens if you accidentally double click it.
But if you're seeing .compiled files, you're publishing your app in such a way that it expects to be formally installed- it's not enough to just copy things to production. You have to run the installer program too. If this is an app you know is already deployed, that seems a bit unnecessary.