The introduction of ASP.NET in 2002 signified a big change in Microsoft server-side technologies for building Web sites. It represented a shift from the interpreted Active Server pages (ASP) to compiled ASP.NET pages. The compiled ASP.NET Web applications were much faster than the interpreted ASP applications and presented the developer with a variety of advantages, one of them being dynamic compilation.

Dynamic compilation allows ASP.NET to automatically detect changes, compile the changed files, and store them for future use. It also ensures that the applications are up to date. With the introduction of the beta version of ASP.NET Version 2.0, Microsoft has further refined the compilation model and has made many changes to the core structure of ASP.NET. In this article we will compare the compilation model of ASP.Net 1.X and ASP.NET 2.0. We will also look at some of the new features in ASP.NET 2.0 that simplify the development process and allow developers to concentrate on the most important task of all: coding.

ASP.NET 1.X Compilation Model
ASP.NET supports a code-behind model, meaning the ASPX page can have a code-behind page associated with it. There is a complex relationship between the ASPX page and the code-behind page. The code-behind page is derived from the System.Web.UI.Page class, and the ASPX page in turn inherits from the code-behind page. Figure 1 shows the inheritance model in ASP.NET 1.X.

Visual Studio.NET always implements the code-behind model. If we create a Web form named Webform1. aspx, Visual Studio.NET automatically creates a code-behind page and names it as Webform1.aspx.cs.Visual Studio manages the relationship between the ASPX file and the code-behind file by the page directive in the ASPX file as shown here:

<%@ Page language="c#" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false"
Inherits="SampleWeb.WebForm1" %>

The Visual Studio Web form designer uses the code-behind attribute to refer to the code-behind page and tells the designer where to find the file. Visual Studio pre-compiles all the code-behind pages into a project assembly and places it in the bin directory. Because my Web project is named SampleWeb, the DLL is named SampleWeb.DLL. The Inherits attribute tells the compiler the class in the project assembly from which the ASPX page inherits. In the previous code snippet, it tells the compiler to look for a class called WebForm1 in the SampleWeb.DLL. If we want each page as a separate assembly (instead of the code-behind pages being precompiled into a project file), the framework supports a slightly different model for ASP.NET. In this case there is no code-behind attribute in the page directive. The link between the ASPX file and its corresponding code-behind page is managed by the Src attribute. The Src attribute points to the code-behind page as shown here. The code runs exactly the same way in both the models:

<%@ Page language="c#" Src="WebForm2.cs" AutoEventWireup="false" Inherits="WebForm2 " %>

ASP.NET compiles the ASPX page the first time the user requests it and then stores it into its cache. Next time around ASP.NET checks the cache to see if the copy of the page exists. In case it cannot find one, it creates a temporary source code file that represents the Page class. It puts it in the temporary ASP.NET files folder that exists inside the Windows\Microsoft.Net\Framework\Version\TemporaryASP.NETFiles\<Website> folder. Let's look at a simple example. Listing 1 shows the ASPX page WebForm1. aspx. Listing 2 shows the code-behind page that is associated with the ASPX file. On compilation, you will notice a class file in this temporary folder that has a class that is named WebForm1 _aspx just like the ASPX page. However, the dot has been replaced by an underscore. The auto-generated class inherits from the code-behind class as instructed, which in our example is SampleWeb. WebForm1.

There are a lot of confusing things with the current way of doing things. There is a complex division of responsibility between the base class (i.e., the code-behind page) and the ASPX page. The event-handling plumbing is done in the code-behind page as shown in Listing 2. If we look at the code-behind file example, we see that each and every control that exists on the ASPX file has to be declared in the code-behind file. The ASPX file and the code-behind files have to be kept synchronized. Visual Studio.NET handles this synchronization transparent to the developer. In this model there is a good probability that a developer could accidentally change the ASPX file outside the Visual Studio environment without updating the code-behind file. This would easily bring down a working Web application because of the mismatch between the code-behind and the ASPX pages. The current model also makes it very difficult for a developer to implement the code-behind model without the help of a tool like Visual Studio. Let's now look at ASP.NET 2.0 and how the new model eliminates this problem.

ASP.NET 2.0 Compilation Model
The first thing that needs to be pointed out about the ASP.Net 2.0 model is that the complex division of responsibility between the code-behind and the ASPX page is removed. Listings 3 and 4 show the ASPX page and the code-behind file. Notice that the code-behind file is much cleaner than the ones in ASP.NET 1.X. The code-behind page just contains the user-defined code. It no longer contains all the control declarations that are needed to synchronize the ASPX file and the code-behind page in ASP.NET 1.X. In ASP.NET 2.0, the association between the ASPX and the code-behind page is specified with a new directive called Compilewith shown in the following code snippet:

<%@ Page Language="C#" CompileWith="Default.aspx.cs" ClassName="Default_aspx" %>

Also, notice a new directive called ClassName, which in this case is Default_aspx. This is the name of the class that the page would be given when it is compiled. Another interesting point is that the class name of the code-behind page is the same as that of the ASPX page. So the obvious question is how is it possible to have the same class declaration in two different files? This is made possible by the new construct partial class in .NET Framework 2.0 that allows a single class to exist in multiple files. In this case, when an ASPX page with a new code-behind file is requested, the ASP.NET 2.0 runtime will actually combine the class definition that is spread in the ASPX page and the code-behind page into a single class named Default_aspx. Another change that I would like to point out is that the code-behind page no longer inherits from System.UI.web.Page and it also no longer needs to define all the controls that are defined in the ASPX page. This is because now we are dealing with one class, unlike before where we had two different classes with one inheriting from the other. Figure 2 shows the inheritance model in ASP.NET 2.0.Visual Studio 2005 beta no longer pre-compiles all the code-behind pages into the project assembly. Because this intermediate step of pre-compilation is avoided, there is no need to rebuild the entire project for a single change. Another big advantage is that Visual Studio 2005 IDE now provides the same level of support Intellisense to a developer who chooses to follow the single file model for development.

New Compilation Features
In ASP.NET 1.X, the two modes of compilation available were either compilation on first request of each page or batch compilation where in many temporary ASPX pages were compiled into a single assembly. Batch compilation is preferred in some scenarios to reduce the delay on the first page request. Listing 5 shows how to set up batch compilation in ASP.NET 1.X via the Web.config file. ASP.NET 2.0 has simplified the batch compilation process and all that is needed is a single URL request:

http://localhost/myapp/precompile.axd

This mode of compilation is known as in-place compilation. The advantage of using in-place compilation is that it helps eliminate the time delay in batch compilation on the first request. It also helps to identify the compilation errors before the users find them.

ASP.NET 2.0 supports yet another way for compiling and deploying Web applications: full deployment pre-compilation. All the code-behind, ASPX, and HTML files are compiled into one or more assemblies or executables. This type of compilation helps to protect the intellectual property in the code because the ASPX and code-behind files no longer have to be deployed as such on the production server. The compiled executable can then be copied to its destination via Xcopy or FTP. This model of compilation provides the greatest performance and security. However, it comes at a cost because we will not be able to modify the Web site once it's deployed. For full deployment pre-compilation, we use a command line tool called aspnet_compiler. The result of pre-compiling is a site with a bin directory that contains assemblies and a number of stub files with the same name as the original pages. However, when you open them you will notice that the files contain no code or HTML markup inside, although the user will not notice any difference when browsing the Web site. The code below shows the command line option to precompile the Web site.

aspnet_compiler /v /<websitename> -p <source path> <destination>

<websitename> is the name of the Web site <source path> is the location of the Web site to compile, and <destination> is the file path where the compiled assemblies have to be deployed.

The Code Directory
The code directory is another special folder that is used by ASP.NET 2.0. We are already familiar with the bin directory where ASP.NET 1.X stores the precompiled assemblies. The code folder in ASP.NET 2.0, on the other hand, is used to store class files that are to be dynamically compiled at runtime. These classes are then automatically referenced by the application that contains the code folder. The biggest advantage of using the code directory is that the project no longer needs to be built before deployment and the classes also need not be referenced. This greatly simplifies the development process. Figure 3 and Listings 6, 7, and 8 show a very simple example of using the code directory. CodeClass.cs is placed in the code directory, and contains a static method that returns the string. The Web page assigns the value of the string to the label when the button is clicked. Once the CodeClass is placed in the directory and the appropriate code is written in the button click method, any change to the string in the CodeClass GetLabelText method is reflected on the Web site by a simple refresh.

ASP.NET 2.0 also allows Web developers to set the hierarchy structure of the code directory, giving them the freedom to organize the class files in the folder. The only requirement is that the topmost-level directory should be named ?code? (not case sensitive), and it should be below the application root. Listing 9 shows an example of hierarchy inside the code folder.

These classes are available anywhere in the application folder. All of the code that is placed in the code directory is compiled into a single assembly. Because of this, all the files in the code folder should belong to a single programming language (i.e., they can either be in C# or in VB.NET). However, we can configure the Web site to treat different folders in the code folder as separate compilable units. This is done by defining a <codeSubDirectories> element in the <compilation> element of the Web.config file and adding a reference to the subfolder. Listing 10 shows how to define two subfolders in the code folder. The names are just for reference. The programming language to be used in the folder is no way linked to the directory name.

Conclusion
This article has looked at the difference between the compilation model of ASP.Net 1.X and ASP.NET 2.0. Some of the concepts, such as partial class, have greatly simplified things for developers who choose to follow the code-behind model for ASP.NET development without the use of an IDE like Visual Studio.NET. The other features, such as deployment pre-compilation, clearly translate to better performance and protection intellectual property. On the whole, with the introduction of ASP.NET 2.0 Microsoft has provided developers with a wealth of features with plenty of flexibility.