Developer specific app.config/web.config files in Visual Studio

Question

We have several .NET projects where we store certain settings in configuration files.

Now each developer will have their own configuration files that differ a little (different connection strings to connect to local databases, different WCF endpoints, etc.)

At the moment we tend to check out app/web.config files and modify them to suit our needs.

This leads to many problems since from time to time someone will check in their own settings or loose custom configuration when getting latest version from TFS.

How do you deal with situations like this? Or don't you have this problem at all?

Answer 1

We use a system that combines several of the existing answers on this page, plus draws on this suggestion by Scott Hanselman.

In short, what we did was to have a common app.config / web.config, and to have most of the specific settings in individual files, as suggested by other answers here. e.g. for our SMTP settings, the app.config contains

<system.net>   <mailSettings>     <smtp configSource="config\smtp.config" />   </mailSettings> </system.net> 

This file is in source control. However, the individual files, like this, are not:

<?xml version="1.0" encoding="utf-8" ?> <smtp deliveryMethod="Network">   <network host="127.0.0.1" port="25" defaultCredentials="false" password="" userName ="" /> </smtp> 

That's not quite where the story ends though. What about new developers, or a fresh source installation? The bulk of the configuration is no longer in source control, and it's a pain to manually build all of the .config files they need. I prefer to have source that will at least compile right out of the box.

Therefore we do keep a version of the .config files in source control, named .config.default files. A fresh source tree therefore looks like this:

Still, not really any use to the developer, since to Visual Studio they're just meaningless text files. Hence the batch file, copy_default_config.bat, takes care of creating an initial set of .config files from the .config.default files:

@echo off @REM Makes copies of all .default files without the .default extension, only if it doesn't already exist. Does the same recursively through all child folders. for /r %%f in (*.default) do (     if not exist "%%~pnf" (echo Copying %%~pnf.default to %%~pnf & copy "%%f" "%%~pnf" /y) ) echo Done. 

The script is safely re-runnable, in that developers who already have their .config files will not have them overwritten. Therefore, one could conceivably run this batch file as a pre-build event. The values in the .default files may not be exactly correct for a new install, but they're a reasonable starting point.

Ultimately what each developer ends up with is a folder of config files that looks something like this:

It may seem a little convoluted, but it's definitely preferable to the hassle of developers stepping on each other's toes.

Answer 2

In your Web.config use source from other files

<configuration>     <connectionStrings configSource="ConnectionStrings.config" /> ... </configuration> 

Keep the web.config in version control and don't do it for ConnectionStrings.config. Now all developers have one file for the connection string.

You can do this for all the settings that are local dependant.