Precompile If You are Code Shy

You can precompile a Web site project before it is made available to users. This provides many advantages, which include faster initial response time, error checking, source-code protection, and efficient deployment. This is particularly important in large sites where there are frequent changes in Web pages and code files.

You can also compile a project by using the Web application project model. In that model, all code files (standalone, code-behind, and class files) in the project are compiled into a single assembly and stored in the Bin directory. Because compilation creates a single assembly, you can specify attributes, such as assembly name and version. You can also specify the location of the output assembly if you do not want it to be in the Bin directory.

By default, the Web pages and code files of a Web site project are compiled on the Web server 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. Therefore, subsequent requests to the same page are very efficient. As an alternative to this dynamic compilation, you can precompile a Web site project.

Precompiling an ASP.NET Web site project provides the following advantages:

• Faster initial response time for users, because pages and code files do not have to be compiled the first time that they are requested. This is especially useful on large sites that are frequently updated.

• A means to identify compile-time bugs before users see a site. (You can also accomplish this when you compile a project in Visual Studio.)

• The ability to create a compiled version of the site that can be deployed to a production server without source code. This makes sure that that people who have access to the production server will not be able to view the source code.

ASP.NET offers the following 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. The files that you deploy to the production server can be made read-only or updatable. The following sections provide more details about each option.

By default, ASP.NET compiles the application the first time a page in the application is requested by a Web browser. If you make a change to a file in the application, the next time a page is requested the ASP.NET runtime determines the dependencies of the changed file. ASP.NET then recompiles only the files that are affected by the change.

Use default compilation in the following situations:

• When you are developing and testing a Web site.

• For Web sites that have primarily static information.

• For Web sites that are not frequently changed.

However, do not use default compilation Web site in the following situations:

• When you are concerned about storing source-code files on the production server. (Anyone who has access to the folders that contain the Web site files will be able to see the source code).

• When you are concerned about possible delays when the first request is made to the Web site in production. (You should test the site determine if the delay is noticeable. For most sites it is not noticeable.)

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 puts 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.

Use in-place compilation in the following situation:

• You make frequent changes to pages on the Web site and you don't want to have to redeploy the site each time you make a change.

• When you are concerned about storing source-code files on the production server. (Anyone who has access to the folders that contain the Web site files will be able to see the source code).

• When you are concerned about possible delays when the first request is made to the Web site in production. (You should test the site determine if the delay is noticeable.)

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 ordinarily 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 the site after you compile them. For example, you can change the arrangement of controls, colors, fonts, and other appearance aspects of pages.

When the site runs the first time, ASP.NET performs additional compilation in order to create output from the markup.

Use precompilation for deployment with updatable UI in the following situation:

• You want to be able to modify the markup in .aspx pages without requiring the whole Web site to be recompiled. Typically, this is an advantage only for very large sites for which compilation takes a significant amount of time.

• You are not concerned about storing some of your source code on the production server.

--Microsoft