Fun Pet Trick 6: Precompilation of ASP.NET Applications

Fun Pet Trick #6: Precompilation of ASP.NET Applications

By Scott Guthrie

ASP.NET has always supported a dynamic compilation model, in which pages and resources are dynamically compiled the first time they are accessed. This was true in ASP.NET version 1.0 (even in code-behind scenarios where the ASPX page was always compiled the first time the page was hit), and even more true in ASP.NET version 2.0 (where dynamic compilation is now supported for even more types of files and resources).

Dynamic compilation has two downsides:

A small first-time hit occurs when accessing a page or resource (since a compiler is spinning up). The compiled output is persisted (so the hit only occurs once), but the overall time to compile can add up significantly on large sites of thousands of pages.
When you dynamically compile, you need to have the source code deployed on the production server. This makes it harder to resell applications—because your customers then effectively get your source code (resulting in your having less control over it).

ASP.NET solves both of these issues by supporting a precompilation option. This precompilation option supports precompiling all resources within an ASP.NET application—ASPX pages; code-behind; inline code; code, themes, and resources directories; ASCX, ASMX, ASAX, files; and so on.

This ensures that no runtime hit whatsoever happens when a page is first requested off of a server; everything is compiled and ready to go when the files are copied up on the system.

The precompilation utility also automatically strips out all source code from the application; this includes both new code-behind as well as code within the ASPX page, and even the markup within the files. This provides total protection of all of your intellectual property (IP).

The following steps walk you through how to precompile an application using the Alpha version. Note that VS .NET will automatically have a Build Menu option within Beta (so that you can easily kick-start the build within the IDE). For now, though, you need to use a command-line option to enable this (note that this will continue to ship in the Beta and final release to enable batch compile options, as well as automated, script-based compile scenarios).

Build an ASP.NET application in a directory called c:\PetTrick. Note that if you don't have an existing application lying around, try copying and using the one available at this URL: http://www.asp.net/Forums/ShowPost.aspx?tabindex=1&PostID=300870.
Open a command-line window.
Use the aspnet_compiler.exe utility within the Framework's redistribution directory to compile the application to a new target directory (note that this isn't on the default system path, so you'll need to fully qualify the compiler name).

Multiple options are enabled when using aspnet_compiler.exe—try just adding a -? to the end of the arguments list to see all of them.

 c:\WINDOWS\Microsoft.NET\Framework\v1.2.30703\aspnet_compiler.exe -v /PetTrick -p c:\PetTrick c:\PetTrickCompiledTarget

The preceding statement compiles an existing application that lives in the PetTrick directory into the PetTrickCompiledTarget directory.

To run the built application, go into InetMgr and set up an IIS virtual root application called PetTrick to point at the PetTrickCompiledTarget directory (note that the -v option on the tool asks for the final virtual root name in order to make sure you get the virtual hierarchy right when burning in references).

When you browse to the PetTrick root directory, the application will work as normal. When you open the PetTrickCompiledTarget directory, though, you'll notice that no ASPX source code is left. Instead, you'll just find marker files. All code within the pages, code, and resources directories have been precompiled down into assemblies in the bin directory.

You can now deploy this on a remote machine and get fast startup performance (no compile-time hit), and all your source code IP is safe.