In ASP.NET, there are three compilation models, which are useful in different scenarios. The first one is called Classic precompilation, and is used when you work with an ASP.NET Web Application project type. With this method some parts of the page, such as the code-behind class files, referenced assemblies, etc. are precompiled, and other parts, such as the markup logic (.aspx files) are dynamically compiled at runtime. You can only use this type of compilation with the code-behind model.
The second method is called Dynamic compilation. With it, all of the pages, code files, resources, etc. are copied to the server as is, and ASP.NET compiles them to an executable when the first user requests a site. An obvious drawback of this model is that the first requests of the page take more time to fulfill, so users must wait more. A great advantage is that you can always update the files on the server, without the need of stopping and recompiling your application.
Our third method is Site precompilation. Site precompilation allows you to compile your whole site, even the .aspx files into binaries, which could be transferred to the server. There is no performance penalty, but the updates are considerably trickier.
Be aware of that, from the above three, the default model is Dynamic compilation.
Using the aspnet_compiler:
This is the exe which lets you compile your applications, as might you have guessed it. The syntax is the following: aspnet_compiler –m metabase path –v virtual directory path –p physical path target directory.
There are two other important switches for the exam: -u for updatable, which when specified, compiles only the code files, themes, resources, etc., but not the .aspx or .asmx files, thus allowing you to update them later. As you might have guessed, there’s a potential drawback here, because the markup files need to be compiled dynamically.
The other switch, namely –fixednames, lets you specify a fixed name for the assemblies you compile. This is useful, because by default, aspnet_compiler does generate new names for assemblies in every compilation. And if you’d only like to update a specific site, there would be issues with assembly naming between the old and the newly compiled sites. But specifying –fixednames, and a fixed name solves this issue.
Publishing from Visual Studio:
If you have Visual Studio installed (Express editions won’t count here), you have a good alternative for the aspnet_compiler in your hands. Simply use the Publish Web Site Tool, for achieving the same effect. There are two options here, which should be mentioned: the Allow this precompiled site to be updatable check box, which has the same effect as the –u switch, and the Use fixed naming and single page assemblies, for the –fixedname switch.
Overcoming limitations: aspnet_merge:
The aspnet_compiler.exe has some limitations, and in a large production environment, you should also use aspnet_merge.exe. For using this tool, you need your web site previously compiled by aspnet_compiler.exe. There are three scenarios, when it’s particularly useful:
You need one assembly, and nothing more for a website. Just call aspnet_merge.exe with the –o switch, and a name specified for the .dll file. Be aware of that the referenced assemblies cannot be merged into this assembly, therefore, it’s not enough to reference a GAC-located assembly, you must include it into your project.
Combine the assemblies of the website’s UI into one assembly. Specify the –w switch, and aspnet_merge will combine these files into a single assembly.
Combine the assemblies of your site’s UI into different assemblies, depending on the folder, which in they are located. Simply: every directory will have one UI assembly. To get this behavior, don’t provide any switches.