• Choose a category
• All
• Classic-Fiction

Precompilation can take two forms: in-place precompilation and deployment precompilation.

Note

Site precompilation is sometimes sold as a feature that saves you from having to deploy your source code to the production environment. This is definitely the wrong way to approach things. ASP.NET allows you to deploy pages with their source code-behind classes, but it doesn’t mandate it. It’s ultimately your choice, and the option has both pros and cons. If you don’t want to deploy source code, just opt for a Web application project instead of a Web site project. Site precompilation can be applied to any ASP.NET project regardless of the type and in spite of the Visual Studio tooling support that for some reason is only offered if you opt for a WSP.

In-Place Precompilation

In-place precompilation consists of running a tool over the entire set of project files to request each page as if it were being used by end users. As a result, each page is compiled as if it’s for ordinary use. The site is fully compiled before entering production, and no user will experience a first-hit compilation delay.

In-place precompilation usually takes place after the site is deployed but before it goes public. To precompile a site in-place, you use the following command, where /yourApp indicates the virtual folder of the application:

aspnet_compiler -v /yourApp

Note that with the previous syntax, YourApp is assumed to be deployed within the default Web site. If that is not your case, you might want to indicate the site explicitly, as shown here:

aspnet_compiler -v /W3SVC/2/Root/YourApp

In this case, you are addressing YourApp within the Web site characterized by an ID of 2.

If you precompile the site again, the compiler skips pages that are up to date and only new or changed files are processed and 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 is essentially a batch compilation that generates all needed assemblies in the fixed ASP.NET directory on the server machine. If any file fails compilation, precompilation will fail on the application. The ASP.NET compiler tool also supports a target directory. If you choose this option, the tool will generate all of its output in a distinct directory. Next, you can zip all of the content and deploy it manually to the IIS machine. I’ll discuss the command line of the ASP.NET compiler tool in a moment.

Precompilation for Deployment

Precompilation for deployment generates a representation of the site made of assemblies, static files, and configuration files—a sort of manifest. This representation is generated on a target machine and also can be packaged as MSI and then copied to and installed on a production machine. This form of precompilation doesn’t require source code to be left on the target machine.

Precompilation for deployment is also achieved through the aspnet_compiler command-line tool. Here’s a common way to use the tool:

aspnet_compiler -m metabasePath

-c virtualPath

-p physicalPath

targetPath

The role of each supported parameter is explained in Table 2-1.

Table 2-1. Parameters of the aspnet_compiler Tool

Switch

Description

–aptca

If this switch is specified, compiled assemblies will allow partially trusted callers.

–c

If this switch is specified, the precompiled application is fully rebuilt.

–d

If this switch is specified, the debug information is emitted during compilation.

–delaysign

If this switch is specified, compiled assemblies are not fully signed when created.

–errorstack

Shows extra debugging information.

–m

Indicates the full IIS metabase path of the application.

–f

Indicates that the target directory will be overwritten if it already exists and existing contents will be lost.

–fixednames

If this switch is specified, the compiled assemblies will be given fixed names.

–keycontainer

Indicates the name of the key container for strong names.

–keyfile

Indicates the physical