You already saw how Visual Studio 2010 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 earlier versions of ASP.NET 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 this Figure.
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 this 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 did not 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 provides a few ways to precompile your entire application with a single command that you can issue through a command line. One type of compilation is referred to as in-place precompilation. To precompile your entire ASP.NET application, you must use the aspnet_compiler.exe tool that comes with ASP.NET. You navigate to the tool using the Command window. Open the Command window and navigate to C:WindowsMicrosoft.NETFrameworkv4.0.xxxxx. When you are there, you can work with the aspnet_compiler tool. You can also get to this tool directly from the Visual Studio 2010 Command Prompt. Choose Start ➪ All Programs ➪ Microsoft Visual Studio 2010 ➪ Visual Studio Tools ➪ Visual Studio Command Prompt (2010).
After you get the command prompt, you use the aspnet_compiler.exe tool to perform an in-place precompilation using the following command:
aspnet_compiler -p "C:Inetpubwwwrootcode" -v none
You then get a message stating that the precompilation is successful. The other great thing about this precompilation capability is that you can also use it to find 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 employ this precompilation method. The next precompilation option is commonly referred to as precompilation for deployment. This outstanding capability of ASP.NET 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 also after your application is compiled, you simply 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.
However, before you take these precompilation steps, create a folder in your root drive called, for example, code. This folder is the one to which you will direct the compiler output. 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]
Therefore, if you have an application called ThomsonReuters located at C:Websitescompile, you use the following commands:
aspnet_compiler -v /compile -p C:Websitescompile C:code
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. 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 /compile. The next command is –p, which is pointing to the physical path of the application. In this case, it is C:Websitescompile. Finally, the last bit, C:code, is the location of the compiler output. Table describes some of the possible commands for the aspnet_compiler.exe tool.
| Command | Description |
|---|---|
| -m | Specifies the full IIS metabase path of the application. If you use the -m command, you cannot use the -v or -p command. |
| -v | Specifies the virtual path of the application to be compiled. If you also use the -p command, the physical path is used to find the location of the application. |
| -p | Specifies the physical path of the application to be compiled. If this is not specified, the IIS metabase is used to find the application. |
| -u | If this command is utilized, it specifies that the application is updatable. |
| -f | Specifies to overwrite the target directory if it already exists. |
| -d | Specifies that the debug information should be excluded from the compilation process. |
| [targetDir] | Specifies the target directory where the compiled files should be placed. If this is not specified, the output files are placed in the application directory. |
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. However, 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.
Note that this compilation process does not 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 cannot 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 extensions of these file types to .aspx; they are then compiled into the Code.dll like all the other ASP.NET files.