How ASP.NET Compilation Works

When ASP.NET receives a request for a page, it first looks to see whether it has a current compiled version of the page. When the sources for a page are modified and saved, ASP.NET invalidates the previous version of the page and creates a new one when it is needed. When the first request for a page in an application is received, ASP.NET will try to generate code for all pages in the directory and compile them into a single assembly for greater efficiency.

Knowing how ASP.NET compilation works is helpful, particularly when troubleshooting a problem with an application. ASP.NET creates a directory under the root Microsoft .NET Framework directory for generating and compiling code. The resulting assemblies (and code, when debugging is enabled) can be found here. The directory used by ASP.NET is called Temporary ASP.NET Files. In a default .NET Framework version 1.1 installation, these assemblies can be found in the \Microsoft.NET\Framework\v1.1.4322 directory under \Windows or \WINNT. Navigate to this directory on your machine, and you’ll find a subdirectory corresponding to each application root of your Web server where ASP.NET pages have been requested. For example, root corresponds to the default root Web application defined in the Internet Services Manager. Inside that subdirectory is another directory that contains yet another whose name appears to be randomly generated. In that inner subdirectory is a set of files generated by ASP.NET. These files are used to track when pages are updated, when pages need to be recompiled, and dependencies between pages. Figure 10-5 is a view in Microsoft Internet Explorer of the types of files you will find in the temporary directory.

Figure 10-5: Temporary ASP.NET files

The .web files are used by ASP.NET to manage when files are updated. The .xml files correspond to a page in the application directory that has been compiled. In this directory listing, only one .dll is present, although a collection of .xml files exists. If we run ILDASM on that .dll, we can see that the assembly contains page classes for each page in which an .xml dependency file has been created. When a page from the root directory was first requested, a single assembly was generated by creating and compiling code for all the pages present. Figure 10-6 shows the listing as seen in ILDASM.

Figure 10-6: Batch compilation

The .xml file contains information about the dependencies used by ASP.NET to track which source files were used in compiling the page class and the name of the resulting .dll. For a simple page, like Cookie.aspx from Code Listing 10-3, the dependencies are simple. Figure 10-7 shows that we’ve opened the .xml file in Microsoft Notepad and only the .aspx file was used.

Figure 10-7: Dependency listing

The assem attribute indicates the name of the assembly into which the page source was compiled; the filedep element lists the files that contributed to the final code. If we modify the source file, ASP.NET sees the change and the .xml file is updated when the page is next requested. The assem attribute will point to a new DLL that appears in the temporary directory. That assembly will contain just the updated cookie page class, whereas the rest of the page objects will still be executed from the previously created assembly.