ASP.NET 2.0 Compilation In A Nutshell

" It's all about first hit "

ASP.NET 2.0 Compilation is one of the best changes done on v 1.x, but to get the full picture you should understand how compilation was maintained in older versions. In ASP.NET 1.x, if you are working using code behind model, after you compile your site everything is placed in one, or more, assembly, and the ASPX pages stay untouched, until the user requests a page for the first time, that was somehow confusing, what actually happens is that when you compile your application; you only compile the code-behind files, while the ASPX files, are getting compiled upon request, in other words after they are parsed by ASPX parser, the pages are compiled and merged with the code behind file which is already compiled ( MSIL ) and then you get out of this by an assembly, this assembly is compiled using JIT compiler to machine language, and then gets executed emitting the final output ( HTML ) to the user and the compiled page is written or cached to disk for future requests, that is what happens upon the first request, but for all upcoming requests the request goes directly to the previously compiled assembly, and that is a huge deal of time saving, this explains why you were always feeling the first hit to your page is sluggish, but any later requests are very fast!

After you finish developing your application you'll likely need to change your application which in turn implies recompiling your application, so again after users start to hit your application , modified one, for the first time they will suffer poor performance, but developers used to bypass this first hit long response time, by writing a script that hits or requests each and every page in the entire application, so for future requests the application will respond in no time !

The above scenario gave birth to precompilation in ASP.NET 2.0, so here we have 2 kinds of compilation , In-Place Precompilation and Precompilation for Deployment.

ASP.NET 2.0 In-Place Precompilation

Simply, that is a solution for the first hit problem, here you can just make a call for axd file that hits each and every page in your application that will save you the first time request sluggishness, you can do that by calling : http://Server/ApplicationName/Precompile.axd , this if you your using IIS, but if you are using the personal web server you will format it like this : http://Server:PortNumber/ApplicationName/Precompile.axd


If you try to access the precompile.axd you will get an 404 error, I tried to figure out what's happening and after some search in KBs and forums, I figured out that this feature is not supported anymore!, so the above axd method is just mentioned for keeping record ( I found some posts saying that it's been stopped since Beta 2, and replaced by aspnet_compiler which we'll discuss in the following section).so this feature has been dropped from the early versions.


The old way of compilation that was known as Pre-Runtime compilation is still valid, in which you compile your code-behind files into one assembly or more placed in the bin directory, and the webforms are just compiled upon request, also you should know that the code is getting compiled by JIT from MSIL into Machine code.!

ASP.NET 2.0 In-Place Precompilation Revisited ( aspnet_compiler )

In this section, we're gonna examine using the In-Place Precompilation using the command prompt utility aspnet_compiler, you can browse to this utility from Visual Studio 2005 Command Prompt, and then browse to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50xxx It’s good to see all the arguments the aspnet_compiler is taking, try typing this into the command prompt aspnet_compiler /? You will get a full description d the compiler tool, in the following table I will show you the most important switches for aspnet_compiler





This is the virtual path of the web application to be compiled

This should be used with –p switch but –p is optional if not passed the IIS metabase if used to lookup the virtual path location


Physical location of virtual path



Overwrites previous compilation output

All previous contents are lost


Shows debug information while compiling


For complete recompilation

Helpful with –targetDir


Output location

If not specified output is written to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files


Path to strong name key file

Strong name key files used to digitally sign your assemblies and to publish to Global Assembly Cache (GAC)


To generate assemblies with the same names in the output directory

Whenever you maintain pre deployment compilation you get assembly files named with a random pattern so in case you update the application you will get ended with a lot of assemblies, so this switch is very important it generates and overwrite existing assemblies.

For the in-place precompilation, you can create a simple web application call it CompilationTest, you can leave it as it is, or write any simple code in Page_Load, then you can enter the following into the command prompt

aspnet_compiler -v /CompilationTest

After few seconds you will get the result of your compilation.

The output is written to the Temporary ASP.NET Files special directory, it’s located at the version directory, in this directory you’ll find a folder named with your application name, in this case CompilationTest.

You’ll go through nested folders named using some pattern, and then you will find a DLL assembly starts with App_Web_xxxxxxxx.dll, this is the assembly containing all the code for your application, also you will find an XML based file with .compiled extension if you try to open this file you will get a list meta data for ASPX page and code behind files as well; one file is created for one aspx page, there is one more file called hash.web; I opened this file found this key “cb06f3a30ef12111”, actually I couldn’t figure out the use of this file, but it seems to be for versioning, also sometimes you might get an error saying that another process is holding or locking this file, if you get such an error, try to stop the windows indexing service.

Pre- compilation For Deployment ( aspnet_compiler )

The Pre-Compilation for Deployment, is compiling both the webforms and code behind files, remember the in place precompilation only compiles the code behind files, so this is a great deal of responsiveness, this way you just copy the files and transfer the application directory to your production environment with no pain!

Here also we’ll use aspnet_compiler command prompt tool but this time we shall supply an output directory so the output will be written to the path specified not the Temporary ASP.NET Files.

Try to use the same web application CompilationTest, and add a folder form solution explorer, then add to this folder a webform, and an html file, then go to VS.NET 2005 Command prompt, enter the following :

aspnet_compiler -v /CompilationTest C:\out

The output is written to the destination folder, the output is supposed to be the same as your physical folder, with the same folders tree, also in the bin folder you will find .compiled and .dll files, these assembly files ( .dll ) hold all master pages, all the aspx pages, they’re holding everything in your application, but if you have html or textual files, they are just copied to the output directory, you will find a copy of the html file you have created from solution explorer, the most remarkable thing is that when you open ASPX, ASCX, and ASHX, you will find a single line containing :

“This is a marker file generated by the precompilation tool, and should not be deleted!”.

So these files are simply placeholders, to keep the structure of your web application.

You can xCopy your application to FTP location, also this provides a good deal of protection for your code as you have zero code files, neither .VB nor .CS files included, noting that the APP_CODE directory is getting compiled too.


If you try to output compilation output to a directory that is under the web application folder you will get the following error “ error ASPRUNTIME: The precompilation target directory C:\Inetpub\wwwroot\CompilationTest\CompilationOutput\) cannot be in the same tree as the source application directory (c:\inetpub\wwwroot\CompilationTest\). Also one thing worth trying, after you run your command and precompile your application for deployment, try to run it again, it will fail because the out directory is not empty, to bypass this supply the “-f” switch, to force overwriting old contents of the destination directory!


There is another important use for the precompilation; in case you have any compilation errors they will be thrown during compilation and the process will halt, to try this, delete the code behind file and try to recompile your application using aspnet_compiler command prompt tool, you will get an error saying the code behind file is missing, this way you will be sure your application is error free.


Links to this post:

Create a Link