I'm in a team of people working from various places and on different machines. Everyone has it's own connection string, nhibernate setting (schema etc.) and wcf endpoints. What drives me crazy is that every now and then when someone adds new key to AppSettings section, my settings are overwritten by his. Does anyone know a way to somehow preserve or rather overwrite again certain web.config settings? Maybe somehow replace in on compile time and define them elsewhere?
-
are you using any subversion? if so, remove `web-config` file from that. – NaveenBhat Sep 28 '11 at 08:44
-
1That wouldn't be a solution because he needs entries that are added, but not those that are just changed. – MatthiasG Sep 28 '11 at 08:55
-
1See here: http://stackoverflow.com/questions/305447/using-different-web-config-in-development-and-production-environment for examples on using web.config transforms and for using "included" configuration files. – Jeremy McGee Sep 28 '11 at 09:10
-
What about using two different config files, one that contains the universal appsettings that everyone and the app will use and then the web.config can have all of the custom stuff that's specific to each dev? – CheckRaise Sep 28 '11 at 14:16
1 Answers
Here is the approach we use. In source control we have file web.config.development
with common settings. Every developer on his machine has file web.config
which is basically a web.config.development
merged with developer's individual settings.
Whenever any common changes are made to the web.config.development
, their author announces that (via Skype, or email, etc.) and every developer merges these changes with his own web.config
. In most cases web.config
is not being changed very often, so this is not a time consuming work. However we were thinking about automating this process but have not come up with any good solution so far.
The key point here is that web.config
is not in the source control, it never was, it never will be. That guarantees that individual settings like connection strings won't be overridden accidentally.
P.S. One more point to be considered is the continuous integration (in case you have one). There we have added a step during deployment, on which web.config.development
is renamed into web.config
.

- 55,890
- 9
- 87
- 108