Configuring Deployed Web Site Projects

Web.config files typically include settings that are different depending on which environment the Web application is running in. Settings that commonly differ between a development site and a production site include:

• Connection strings.

• Membership settings. For information, see Configuring an ASP.NET Application to Use Membership.

• Debugging settings.

• Tracing settings.

• Custom errors. For information, see Error Handling in ASP.NET Pages and Applications.

This topic explains options and techniques for deploying Web.config files that are different from the ones that you use for development. For more information about configuration files, see ASP.NET Web Site Administration.

Configuring the Remote Site

You cannot use the Web Site Administration Tool to configure remote Web sites. When the remote computer requires configuration settings that are different from the local computer, this situation is typically handled in one of the following ways:

• Edit the Web.config file on the target server computer after the site has been deployed. The disadvantage of this method is that each time the project is deployed you have to edit the Web.config file on the target computer again.

• Maintain separate versions of the Web.config file for each environment by storing them in different folders. When you deploy the site, you copy the appropriate version of the Web.config file to the location where it should be on the target computer.

• Maintain separate versions of the Web.config file for each environment by assigning different names to them. For example, in the local site you could have Web.config, Web.local.config, and Web.remote.config. In the local site, Web.config and Web.local.config are the same. After you deploy the site, in the remote site you delete Web.config and rename Web.remote.config to Web.config. (You could maintain just Web.config and Web.remote.config, but then if you ever synchronize and accidentally copy from the remote site to the local site, your local settings will be lost.)

• Create XSLT files to transform the Web.config file, and manually apply the transforms on the target server computer after deployment.

Recommended Settings for the Remote Site

For security reasons, you should make the following changes in the remote Web.config file:

• Set the retail attribute of the deployment element to true. This overrides the local settings for tracing and debug mode in the page or in an application-level Web.config file.

• Encrypt sensitive configuration settings such as security settings and connection strings. For more information, see Encrypting Configuration Information Using Protected Configuration.

Inherited Configuration Settings

Because some configuration settings are inherited, you might need to compare the Machine.config file and the root Web.config file in the source and target computers. These files are located in the SystemRoot\Microsoft.NET\Framework\version\CONFIG directory. If you do not have permission to view the root configuration files, you can create a file that contains a complete list of configuration settings for your Web site (including all inherited settings) that is formatted as a proper configuration file. To do this, use the code that is illustrated in How to: View Inherited and Local Configuration Settings Programmatically. You can run the example code that is provided in that topic in both the development and the production environments and then compare the results.

Security Note
Configuration settings are sensitive information; make sure that no users of your production site are permitted to view the configuration information.

See Also

Tasks

Walkthrough: Deploying a Web Site Project by Using XCOPY

Concepts

Editing ASP.NET Configuration Files

Other Resources

ASP.NET Web Site Administration