Web.config Versioning

Currently I am using a shared database model for our development. I know, it's better to use local development databases to do database versioning the right way without one developer breaking everyone el开发者_开发知识库se's code. So that's what I'm trying to get to. I have a question about the web.config file though. How do I ensure that once every dev has his own local development database, he doesn't have to manually change the DB connection string every time he gets an update from source control? What's the best way to do this?

For example, say Johnny Dev commits his web.config that holds a connection string like this:

server=JohnnysBox;database=JohnnyAppDev1;

So now Susie Dev gets an update and she has to change her connection string to this:

server=SUE;database=development;

So now Susie and Johnny keep committing their own connection strings to the web.config file, and every time they get an update, they have to change the connection strings in all applications.

What's the best way to handle this situation so that devs don't mess up each others' connection string settings, but can push other kinds of config file changes to all the other devs when necessary (like a new app setting)?

---

It's only a partial solution, but you could have all the developers create an alias for their own SQL server using cliconfg.

Then the web.config in source control will have eg:

server=LocalServerAlias;database=development

---

For configuration or settings files, what you need to version is:

• a template files (server=@USER_NAME@;database=@DATABASE_NAME@;)
• one or several value files
• one script able to replace the variables by the right values

---

What we do here is to never commit the web.config file to source control. Instead, we commit a web.config.sample file, and each developer merges changes in that file into their own personal web.config file. It's each developer's responsibility to handle those merges.

---

The way I deal with this is to just not check in developer-specific changes to config files.

When a config change needs to be checked in, I start from a 'clean' config file and make the needed changes, then check in. When everyone else does a get latest, they can merge these changes into their local versions.

---

The solution we came up with at my office was that we specifically exclude the web.config from version control, but only in the www folder. This allows developers to make whatever changes they need locally.

In a separate folder, we have a "master" copy of the web.config which is version controlled. As new sections, keys, etc. are added, it's the developer's responsibility to update the master copy.

---

You can create multiple Web.config files depending on the environment the application is running in. Using the transformation syntax you can modify the main Web.config to include or comply with your own local settings.

http://msdn.microsoft.com/en-us/library/dd465326(VS.100).aspx

Afterwards, exclude this custom Web.xxx.config from your repository.

---

We branch the web.config. So, i've got one called Mattweb.config and I can change it at will, and it replaces the web.config ON MY LOCAL MACHINE ONLY with the contents of Mattweb.config. It's requires no intervention by me.

We also branch the "real" web.config, so that I can compare with my own local version to see if any appsettings were added or any other types of changes. Then I just update my Mattweb.config file and all is well again.

---

Use (local) as the sql server name and it always refers to the local server. This should be the default value in the web.config you check into source control.

For production "installs", your installer should ask the user if they want to use a remote sql server and if so, update the web.config files as part of the install process.