16.5. Creating Web Deployment Projects

Many of the problems that arise when deploying an application stem from differences between the development environment and the production environment. The deployed application may need to use a different database back end. Directory permissions may be different between the test and production systems. Web service calls may need to be redirected to a live server instead of test infrastructure. To help with these problems, there is an add-in available for Visual Web Developer for a project type focused on the deployment process itself, called a Web Setup project.

http://go.microsoft.com/fwlink/?linkid=55111

The Web Deployment project leverages the aspnet_merge tool. This tool can take the individual DLLs of a precompiled Web application and combine them into a single DLL. With default settings, aspnet_merge will compile the entire application, including code from the App_Code directory as well as the generated code from the .aspx pages, and combine them into a single DLL for deployment. This not only simplifies the job of deployment but also minimizes the overhead time that would happen to compile specific pages on demand. There will still be a JIT (just-in-time) compilation needed at runtime to covert the IL code to native code. aspnet_merge and the Web Deployment project are not a replacement for the native code generation services provided by the CLR (Common Language Runtime). The main complication that results from using aspnet_merge is that you won't be able to modify a single page and redeploy it individually unless you use the partial precompilation method discussed later.

You create the Web Deployment project in an existing Web site or Web application by selecting Add Web Deployment Project from the Build menu (see Figure 16-6).

The default behavior for the Web Deployment project is to reuse the existing project name with a suffix that ends in _deploy, but you can change this naming as shown in Figure 16-7. It is important to note that although you have the option to change the location of the deployment project, you cannot select the same root folder as the main project.

Figure 16-8 shows the compilation options. If you check the Allow this precompiled site to be updatable box, it will cause your .aspx files to be deployed verbatim without being precompiled and merged with the other files. This is only a partial precompilation, which allows you to modify an individual page later and deploy only that page. If you uncheck that box, however, your .aspx files will be fully precompiled and replaced with files of the same name containing the text "This is a marker file generated by the precompilation tool, and should not be deleted!"

Figure 16-6. Figure 16-6

Figure 16-7. Figure 16-7

In Figure 16-9, you see the options for the assembly outputs. You can opt to have a single assembly, an assembly per directory, or even a separate assembly for each page. There is some additional runtime memory cost for extra assemblies, but unless the site contains a very large quantity of individual pages, this overhead should be negligible.

Figure 16-8. Figure 16-8

Figure 16-9. Figure 16-9

That gives you greater control over compiled outputs, which is nice but doesn't solve the problem of needing different sets of configuration data when deploying the code. You can manage that on the Deployment property page, shown in Figure 16-10, where you can specify configuration sections that should be swapped out for updated versions. Check the Enable Web.config file section replacement box and provide the section name and the name of a file that contains the updated section. The file must not have any other sections in it. It must be a direct replacement for the original section. The Web deployment project simply parses the .config file as XML and swaps the old section with the contents of the specified file. There is no context for configuration inheritance or validation of attribute values. Here is an example where the section we want to replace is connectionStrings and the file that will provide the new section is deploymentConnectionStrings.config:

connectionStrings=deploymentConnectionStrings.config

Figure 16-10. Figure 16-10