……………………………………………….Expertise in .NET Technologies


Posted by Ravi Varma Thumati on July 17, 2009

You already saw how Visual Studio 2005 compiles pieces of your application as you work with them (for instance, by placing a class in the \App_Code folder). The other parts of the application, such as the .aspx pages, can be compiled just as they were in ASP.NET 1.0/1.1 by referencing the pages in the browser.

When an ASP.NET page is referenced in the browser for the first time, the request is passed to the ASP.NET parser that creates the class file in the language of the page. It is passed to the ASP.NET parser based on the file’s extension (.aspx) because ASP.NET realizes that this file extension type is meant for its handling and processing. After the class file has been created, the class file is compiled into a DLL and then written to the disk of the Web server. At this point, the DLL is instantiated and processed, and an output is generated for the initial requester of the ASP.NET page. This is detailed in Figure 3-14.


On the next request, great things happen. Instead of going through the entire process again for the second and respective requests, the request simply causes an instantiation of the already-created DLL, which sends out a response to the requester. This is illustrated in Figure.


Because of the mechanics of this process, if you made changes to your .aspx code-behind pages, you found it necessary to recompile your application. This was quite a pain if you had a larger site and didn’t want your end users to experience the extreme lag that occurs when an .aspx page is referenced for the first time after compilation. Many developers, consequently, began to develop their own tools that automatically go out and hit every single page within their application to remove this first-time lag hit from the end user’s browsing experience.

ASP.NET 2.0 introduces the technology to precompile your entire application with a single command that you can issue directly in the browser. This type of compilation is referred to as in-place precompilation. In order to precompile your entire ASP.NET application, pull up one of the pages in the browser and replace the page name with precompile.axd. So, if you are working with the Web server that is built into Visual Studio 2005, your request is structured in the following format:

http://%5Bhost]:[port]/[Application Name]/precompile.axd

If you are using IIS as the Web server, your request is structured in the following format:

http://%5Bhost]/[Application Name]/precompile.axd

You get a message stating that the precompilation was successful. The other great thing about this precompilation capability is that you can also use it to find any errors on any of the ASP.NET pages in your application. Because it hits each and every page, if one of the pages contains an error that won’t be triggered until runtime, you get notification of the error immediately as you invoke precompile.axd.

The next precompilation option is commonly referred to as precompilation for deployment. This is an outstanding new addition to ASP.NET that enables you to compile your application down to some DLLs, which can then be deployed to customers, partners, or elsewhere for your own use. Not only are minimal steps required to do this, but after your application is compiled, you only have to move around the DLL and some placeholder files for the site to work. This means that your Web site code is completely removed and placed in the DLL when deployed.

To precompile your application for deployment, you must use the aspnet_compiler.exe tool that now comes with ASP.NET 2.0. You navigate to the tool using the Command window. Open the Command window and navigate to C:\Windows\Microsoft.NET\Framework\v2.0.xxxxx\. When you are there, you can work with the aspnet_compiler tool.

Before you do, however, create a folder in your root drive called, for example, Wrox. This folder is the one you ask the compiler to output to. When it is in place, you can return to the compiler tool and give the following command:

aspnet_compiler -v [Application Name] –p [Physical Location] [Target]

So, if you have an application called INETA located at C:\Websites\INETA, you use the following commands:

aspnet_compiler –v /INETA –p C:\Websites\INETA C:\Wrox

Press the Enter key, and the compiler either tells you that it has a problem with one of the command parameters or that it was successful (shown in Figure 3-16). If it was successful, you can see the output placed in the target directory.

In the example just shown, -v is a command for the virtual path of the application—which is provided by using /INETA. The next command is –p, which is pointing to the physical path of the application. In this case, it is C:\Websites\INETA. Finally, the last bit, C:\Wrox, is the location of the compiler output.


The following table describes the possible commands for the aspnet_compiler.exe tool.


After compiling the application, you can go to C:\Wrox to see the output. Here, you see all the files and the file structures that were in the original application. But if you look at the content of one of the files, notice that the file is simply a placeholder. In the actual file, you find the following comment:

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

In fact, you find a Code.dll file in the bin folder where all the page code is located. Because it is in a DLL file, it provides great code obfuscation as well. From here on, all you do is move these files to another server using FTP or Windows Explorer, and you can run the entire Web application from these files. When you have an update to the application, you simply provide a new set of compiled files. A sample output is displayed in Figure 3-17.


Note that this compilation process doesn’t compile every type of Web file. In fact, it compiles only the ASP.NET-specific file types and leaves out of the compilation process the following types of files:

  • HTML files
  • XML files
  • XSD files
  • web.config files
  • Text files

You can’t do much to get around this, except in the case of the HTML files and the text files. For these file types, just change the file extension of these file types to .aspx; they are then compiled into the Code.dll like all the other ASP.NET files.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: