ASP.NET Web Site Precompilation Overview
By default, ASP.NET Web pages and code files are compiled dynamically when users first request a resource such as a page from the Web site. After pages and code files have been compiled the first time, the compiled resources are cached, so that subsequent requests to the same page are extremely efficient.
ASP.NET can also precompile an entire site before it is made available to users. This provides a number of advantages, including:
Faster response time for users, since pages and code files do not have to be compiled the first time they are requested. This is particularly useful on large sites that are updated frequently.
A means to identify compile-time bugs before users see a site.
The ability to create a compiled version of the site that can be deployed to a production server without source code.
Precompilation Options
ASP.NET offers two options for precompiling a site:
Precompiling a site in place. This option is useful for existing sites where you want to enhance performance and perform error checking.
Precompiling a site for deployment. This option creates a special output that you can deploy to a production server.
Additionally, you can precompile a site to make it read-only or updatable. The following sections provide more details about each option.
In-Place Precompilation
You can enhance the performance of your Web site somewhat by precompiling it. This is particularly true in sites where there are frequent changes and additions among ASP.NET Web pages and code files—in a fluid Web site, the extra time required to dynamically compile new and changed pages can affect the users' perception of the site's quality.
.gif "Note") Note |
|---|
Precompiling a site in place effectively performs the same compilation that occurs when users request pages from your site. Therefore, the primary performance improvement is that pages do not have to be compiled for the first request. |
When you perform in-place precompilation, all ASP.NET file types are compiled. (HTML files, graphics, and other non-ASP.NET static files are left as is.) The precompilation process follows the same logic that ASP.NET uses for dynamic compilation, accounting for dependencies between files. During precompilation, the compiler creates assemblies for all executable output and places them in a special folder under the %SystemRoot%\Microsoft.NET\Framework\version\Temporary ASP.NET Files folder. Thereafter, ASP.NET fulfills requests for pages from the assemblies in this folder.
If you precompile the site again, only new or changed files are compiled (or those with dependencies on new or changed files). Because of this compiler optimization, it is practical to compile the site after even minor updates.
Precompilation for Deployment
Another use for precompiling a site is to produce an executable version of the site that can be deployed to a production server. Precompiling for deployment creates output in the form of a layout that contains assemblies, configuration information, information about the site's folders, and static files (such as HTML files and graphics).
After compiling the site, you can deploy the layout to a production server using tools such as the Windows XCopy command, FTP, Windows installation, and so on. Once the layout is deployed, it functions as the site, and ASP.NET fulfills requests for pages from the assemblies in the layout.
Precompiling a site for deployment provides a measure of protection for your source code and other intellectual property. For more information about how the compiler works with files during compilation for deployment, see File Handling During Site Compilation for Deployment.
You can precompile for deployment in two ways: precompiling for deployment only, or precompiling for deployment and update.
Precompiling for Deployment Only
When you precompile for deployment only, the compiler produces assemblies from virtually all ASP.NET source files that are normally compiled at run time. This includes program code in pages, .cs and .vb class files, other code files, and resource files. The compiler removes all source and markup from the output. In the resulting layout, compiled files are generated for each of the .aspx files (with the extension .compiled) that contain pointers to the appropriate assembly for that page.
To change the Web site, including the layout of pages, you must change the original files, recompile the site, and redeploy the layout. The only exception is the site configuration; you may make changes to the Web.config file on the production server without having to recompile the site.
This option provides the greatest degree of protection for your pages and the best performance at startup.
Precompiling for Deployment and Update
When you precompile for deployment and update, the compiler produces assemblies from all source code (except page code in single-file pages) and from other files that normally produce assemblies, such as resource files. The compiler converts .aspx files into single files that use the compiled code-behind model and copies them to the layout.
This option enables you to make limited changes to the ASP.NET Web pages in your site after compiling them. For example, you can change the arrangement of controls, colors, fonts, and other appearance aspects of pages. You can also add controls, as long as they do not require event handlers or other code.
When the site runs the first time, ASP.NET performs further compilation in order to create output from the markup.
| Note |
|---|
A precompiled updatable site does not allow multiple pages to reference the same CodeFile class. |
Precompiling Child Applications
Precompiling a Web site compiles only that site, not any child sites. If a Web site contains a child folder that is marked as an application in IIS, the child application is not compiled when you precompile the parent folder.
Performing Precompilation
You can precompile a Web site using the Aspnet_compiler.exe tool on the command line. For more information, see How to: Precompile ASP.NET Web Sites for Deployment and ASP.NET Compilation Tool (Aspnet_compiler.exe).
Some visual designers such as Visual Studio include commands to precompile a Web site from within the IDE. For more information, see How to: Publish and Sign Assemblies for Precompiled Web Sites in Visual Web Developer and How to: Publish and Generate Fixed Assembly Names in Visual Web Developer and How to: Publish Web Sites (Visual Studio) and How to: Publish and Sign Assemblies for Precompiled Web Sites in Visual Web Developer and How to: Publish and Generate Fixed Assembly Names in Visual Web Developer and How to: Publish and Sign Assemblies for Precompiled Web Sites in Visual Web Developer and How to: Publish and Generate Fixed Assembly Names in Visual Web Developer and How to: Publish Web Sites and How to: Publish Web Sites.
One coding restriction applies in sites that you intend to compile with source protection enabled. It is possible for a base page class (a code-behind class) to reference the associated page class (.aspx file) and page class members using a fully qualified class name. However, this type of reference will not work when precompiling your site with source protection enabled. This is because the base page class from the code-behind file is not located in the same assembly as the page class derived from the .aspx page. For more information on precompilation with source protection enabled, see How to: Sign Assemblies for Precompiled Web Sites.
See Also
Tasks
How to: Precompile ASP.NET Web Sites for Deployment