If you open up the Release transformation file that comes with the default Visual Studio ASP.NET template, you find the following:

The element is definitely one that needs to be updated when you move to a production environment. The Transform element indicates that a given attribute—the debug attribute—must be removed. As a result, when the web.release.config file is transformed, the debug attribute is removed from the element.

The overall idea is that you write a base web.config file for the development environment and then express the delta between it and any other one you might need through transformations. At a minimum, you need a transformation for the release version for the configuration file. The delta results from the transformation applied via the XDT transform. The XDT processor is incorporated in the Web Deployment Tool.

You can have a distinct transformation of the web.config for each build configuration you handle in your solution. Figure 2-17 shows how to define a custom build configuration. After you successfully add a new custom build configuration, you right-click the web.config file and select the Add Config Transform menu item. This will add a new web.Xxx.config file, where Xxx is the name of the new configuration. At this point, you can edit the file at will and add as many XDT tags as needed. The file transformation occurs only when you generate a deployment package from the Project menu.

Figure 2-17. Adding a new build configuration.

Site Precompilation

Another aspect related to deploying an ASP.NET application is the site precompilation. Every ASP.NET page needs an extra step of runtime compilation to serve its markup. As you’ll see in the upcoming chapters, when you author an ASP.NET page you write a markup file (ASPX) plus a code-behind class using C#, Visual Basic, or any other supported .NET language.

In a WSP scenario, you deploy markup and code-behind classes as is and wait for the users to make requests to have them compiled. In a WAP scenario, you deploy markup files and one or more assemblies containing the compiled code-behind classes. In both cases, the dynamic compilation step for each available page is still required at least the first time a given page is served. The WAP project type simply saves you from deploying the source code of your classes.

In Visual Studio, when you attempt to publish a WSP project you are shown a different user interface than for a WAP project where a new term is introduced: site precompilation. In spite of this, site precompilation is a general ASP.NET feature and is not limited to WSP projects. It’s the Visual Studio 2010 user interface that seems to limit it to Web site projects.

Is site precompilation really useful?

Site precompilation consists of programmatically invoking all pages so that the ASP.NET runtime can process them as if a user had already invoked each. The benefit is that users won’t experience any extra delay after the first request. In addition, you catch any compile-time errors that slipped into pages after the previous tests.

Precompilation doesn’t necessarily deliver a huge performance improvement; most of the time, it is a small-scale optimization instead. However, if you have pages that cache a lot of data and take a while to initialize, this little bit of speed can improve the user’s perception