Multiple developers using single web.config with different settings

Question

I'm creating an ASP.Net MVC web app. There are multiple developers on the team that need to have different settings in the web.config file. These settings are for the database connection and a local linux virtual machine that needs to be accessed. There are other things that we will need to add in the future. What is a methodology that can be used for each developer to have their own custom settings in the web.config without the fear of having their local settings being committed to source control?

The deployment configurations will not work because they are running the site through the local development VS web server. We will use the deployment configurations for deploying to different stages in our environment.

Answer 1

Most sections in the config XML file allow you to use a configSource attribute . We used this attribute to put commonly dev-modified sections into a separate file. Each of these commonly modified sections would have a seperate *.dev.config and *.prd.config files. The *.dev.config files were ignored by the source control (git).

The production deployment would then set the configSource attribute to use the *.prd.config files. Again this means you need to keep two sets of configuration up to date. I started working on a solution to keep the *.prd.config and *.dev.config files in sync at the element level, but just never got the time to finish it.

Answer 2

I'm not sure if this is the most high-tech solution, but I just call my web.config "web.config.sample", and add web.config to svn:ignore. This stops developers from accidentally checking it in.

When a new key is added to web.config, you just have to remember to duplicate it in web.config.sample.

When a developer checks out a new copy, they just have to rename and configure this file. I've worked at several companies, and we did this every time, so I'm not sure if there really is any other way to do this.

Edit: You could also set up a pre-commit hook to ensure that nobody has checked in a web.config in a directory that also contains a web.config.sample.

Edit #2: You could also set up a post-commit hook that will e-mail everybody involved when web.config.sample is updated, so their apps don't start failing when they look for missing configuration keys. I'm going to do this in future.