I have an ASP.Net web site (ASPX and ASMX pages) with a single web.config file. We have a development version and a production version. Over time, the web.config files for development and production have diverged substantially.
What is the best practice for keeping both versions of web.config in source control (we use Tortoise SVN but I don’t think that matters)? It seems like I could add the production web.config file with a name like “web.config.prod”, and then when we turnover all the files we would just add the step of deleting the existing web.config and renaming web.config.prod to web.config.
This seems hackish, although I’m sure it would work. Is there not some mechanism for dealing with this built in to Visual Studio? It seems like this would be a common issue, but I haven’t found any questions (with answers) about this.
We use the exact method you describe, it works great, for example we have:
The build script for each environment just deletes the web.config and renames the appropriate one in it’s place. Doing this way allows you to easily source control all of them and very quickly do a diff and see what may be different between environments. Updating a config value across the board is much easier as well…the next time it’s pushed to that environment, it’ll get the new config.