ASP.NET —

The ASP.NET Compilation Model

One of the most important improvements Microsoft has made to the ASP development environment is to build the Web request handling framework out of classes. Pushing request processing into a class-based architecture allows for a Web-handling framework that's compiled. When ASP.NET pages are first accessed, they are compiled into assemblies.

This is advantageous because subsequent access loads the page directly from the assembly. Whereas classic ASP interpreted the same script code over and over, ASP.NET applications are compiled into .NET assemblies and ultimately perform better and are safer.

In addition, compiling the Web request framework allows for more robust and consistent debugging. Whenever you run an ASP.NET application from Visual Studio, you can debug it as though it were a normal desktop application.

ASP.NET compiles .aspx files automatically. To get an .aspx page to compile, you simply need to surf to the .aspx file containing the code. When you do so, ASP.NET compiles the page into a class. However, you won't see that class anywhere near your virtual directory. ASP.NET copies the resulting assemblies to a temporary directory.

Microsoft Visual Studio.Net has always included a tool named ILDASM that uses reflection to reverse compile an assembly so you may view its contents. The result is an easily negotiated tree view you may use to drill down to the contents of the assembly. Right now, that's the important thing. (If you want to peer any more deeply into the assembly and see the actual Intermediate Language, ILDASM will show you that as well.)

Viewing the ASP.NET Assemblies

Here's how to view the assemblies generated by ASP.NET.

  1. To run ILDASM, open the Visual Studio .NET 2005 command prompt and type ILDASM.

  2. Select File | Open.

  3. To find the assembly compiled by the ASP.NET runtime, go to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50110\Temporary ASP.NET Files\aspnetstepbystep\>. You'll see some oddly named directories underneath. The subdirectory is named v2.0.50110 at the time of this writing. The final subdirectory may be slightly different. Poke around until you unearth some DLL files. Depending upon how many times you've run the application, you may see several files. Open one of them. You'll see something similar to Figure 2-3.

Figure 2-3 ILDASM showing the contents of the assembly generated by ASP.NET after surfing to HelloWorld3.aspx.
Figure 2-3 ILDASM showing the contents of the assembly generated by ASP.NET after surfing to HelloWorld3.aspx.

ASP.NET has used this temporary directory strategy since version 1.0. The reason ASP.NET copies these files to a temporary directory is to solve a long-standing problem that plagued classic ASP. Classic ASP Web sites often depended upon COM objects to do complex operations such as database lookups and transactions. When you deploy a classic ASP site and clients begin hitting it, those files become locked. Of course, that's not really a problem-until you decide to upgrade or modify part of the Web site.

Classic ASP locked files during execution, meaning you couldn't copy new files into the virtual directory without shutting down the Web site. For many enterprises, this is a bad option. Because ASP.NET copies the files and the components to the temporary directory and runs them from there, they're not locked. When it is time to update a component, simply copy the new assembly into the virtual directory. You can do that because it's not locked.