A common complaint with ASP.NET 1.x developers is the initial delays experienced by users when an application is accessed for the first time. After all, the initial request ignites a string of processes including runtime initialization, parsing, and compilation of ASPX pages to intermediate language, methods just-in-time compiled to native code, and so forth. Developers have been clamoring for a workaround since ASP.NET's inception, and ASP.NET 2.0 delivers a solution with pre-compilation.
The pre-compilation option
ASP.NET dynamically parses and compiles all ASP.NET files (aspx pages) when the application is first called. The runtime environment caches the compiled results to better serve all future requests. A server reboot or Web server restart means the process begins again when the application is accessed the first time. Also, a change to any of the application files is recognized by the system and the process repeats the first time the application is accessed after the file changes.
Many Web developers view this initial delay with disdain. Pre-compilation omits the initial delays in the application by compiling the application.
The command line
Pre-compilation is available via the aspnet_compiler.exe application installed with the .NET Framework 2.0. It is located in the framework's installation directory (the version number will vary by the version of the Framework installed). This is the default path for the tool:
C:\<windows base directory>\Microsoft.NET
You can get an overview of its options with the -? command line switch, but the following list provides a sampling of the available options:
- m: This switch means you will utilize the full IIS metabase path of the application to be pre-compiled. The IIS metabase path is /LM/W3SVC/1/Root/<application name>.
- v: The virtual IIS path of the Web application to be pre-compiled is used. The virtual path has the following format: /<application name>.
- p: The physical path of the IIS Web application to be pre-compiled is used. It is the complete path to the application directory including the drive. An example is c:\inetpub\wwwroot\<application name>. The v switch must be used with p, so the compiler can resolve any application root references.
- f: Signals whether the target directory is overwritten.
- u: Sets the resulting precompiled application as updateable. It means all markup files (ASPX, ASCX, etc.) are available for updates in the target directory.
- targetDir: The target directory for the pre-compiled application files. The following line pre-compiles the application using the virtual path and the specified target directory: aspnet_compiler.exe –v /<application name> c:\target_directory_name.
If no target directory is specified, the result files are placed in the Temporary ASP.NET Files directory, just as it is when/if the ASP.NET runtime handles compilation upon the first request for an application. The temporary directory has the following default path:
\v2.0.50727\Temporary ASP.NET Files\<application name>
An added benefit with pre-compilation is the ability to catch any errors that may occur during application startup. The errors will be displayed by the tool, but they do not halt compilation.
Hidden source code
Another by-product of pre-compilation is the option to hide any and all application source code. This means another developer will need a disassembler and ilasm to dig into your code. That's right—pre-compilation allows you to distribute an application in nothing but binary assembly files.
The target directory will contain no source code. All classes in the App_Code folder are compiled into one or more assemblies in the bin directory; no source code files (.cs, .vb, .js, etc.) will exist in the target directory. In addition, all master page files will also compile to the bin directory and not exist as viewable. All the code and markup in ASPX, ASCX, and ASHX files, along with any associated code-behind files, exists in one or more assemblies in the bin directory.
The hidden source code can be a good and a bad thing. Other developers cannot view or change the application in any way—not even Web page markup. On the other hand, any application changes (regardless of size) require changing the original source code, recompiling, and deploying it again. This can be a time-consuming process, so it may not be suitable for all applications.
The updateable command-line switch (u) allows you to override this default behavior. Using this switch means that all markup files (ASPX, ASCX, etc.) are included in the output of the pre-compilation process. The files are still available for editing and updating once the application has been deployed. This is often a desirable option when small layout issues may be handled in the source files once the application has been rolled out.
Visual Studio support
Pre-compilation is an option when using Visual Studio 2005 to develop ASP.NET-based applications. The Publish Web Site menu option allows you to push the site to another location as a precompiled application. In addition, a checkbox allows you to set the updateable option.
ASP.NET 2.0's pre-compilation option allows you to pre-compile your Web application to omit the delay with the first application request (as everything compiles). In addition, it provides security, as no source code is viewable in the result and all content files may be hidden.
Miss a column?
Check out the .NET Archive, and catch up on the most recent editions of Tony Patton's column.
Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.
Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a production environment on a daily basis.