维护web.config文件

Question

I'm interested to know how others maintain their web.config files for deployed applications. (assuming no automated deployment mechanism - that is out of the scope of this question)

So during development, some developers might make use of web.config transformations, build/publish their projects (debug/release, test/live configurations), then deploy all published artifacts to a web server and set up IIS. Some developers might build/publish their projects, deploy published artifacts to a web server, set up IIS, then manually update the web.configs for the specific environment (test/live, etc) they are deploying into.

Once inital deployment is done and the application is in production (either in a live or a test environment), how do you go about maintaining web.config files over time if say a database connection string or an app settings key needs changing?

Do you utilize web.config transforms, make your changes in VS re-publish the application, then copy the entire app or maybe just the new web.config to the server?

Do you just manually make changes the web.config on the server?

Do you version control the web.config changes in source control if things like connection strings, app keys etc (not structure) change?

I'm interested to know how others are approaching this.

Currently we make changes to the web.config in production. As we implement new features or bug fixes, we version control those changes, and any changes to the web.config such as new app keys etc. If we have to deploy a new version of the application we will backup the current version on the production server, delete all files exception configuration files, then copy the new version without the config files to the production server, retaining the existing configuration. Then manually compare the existing configuration to the one we have in source control to account for changes in schema.

We're looing at revising this because we want a procedure that is reproducable, and not vulnerable to human error. I'm not convinced that the solution is 100% web.config transforms. Even if you use transforms, it still seems that there is some human intervention required in the deployment because potentially a value in the production config file could have changed and not have been updated in the source control. How are others tackling this?

Answer 1

We use web.config transformations with VS 2010.

You can specify one primary web.config file and use transforms to manipulate it for different environments (ie changing database connection strings). These transforms are automatically rendered when you deploy/publish your project(s).

It also depends on what type of change needs to be deployed. Although typically, our deployment setting is to only replace files that have been updated. So if all we changed was the web.config.production transformation, then that's all that's deployed.

And yes, we do keep all web.config files and their transformations under source control as they are part of applications that rely on them.

There are also certain environments which we open to other teams/developers but don't allow them to change web.config settings so their deployment/publish settings skip the web.config file. Although as a general rule, we don't touch files out on the server directly . We always update files locally so that changes can be tracked via source control and deployed properly.

Answer 2

Source control for us is the master store. Anything that needs to be changed HAS to go into it. Developers that try to by-pass this by modifing config settings on PROD or STAGE sites get busted. If something goes wrong, they are responsible for fixing any issues. Usually after the first all-nighter, they don't do it anymore. The source control configuration files are then built into web.config and settings.config files using xml/xslt

On my current project, I am using a web.config that is the same on all environments, and using configSource to pull in server specific settings

<appSettings configSource="App_Data\appsettings.config"/>

Each environment has it's own settings file

• appsettings.user1.dev.config
• appsettings.user2.dev.config
• appsettings.stage.config
• appsettings.prod.config

The package release script we have, grabs the setting file it needs, and renames to appsettings.config, then the whole release is uploaded. The release can then be tagged in source control.