Managing web.config for teams in VS2010 & TFS

Question

With VS2010's mandate that web.config be included in the project, how do we allow everyone to keep their own custom config file without getting into source control problems?

Previously, we would simply leave web.config out of our project, allowing everyone to keep their own local version of web.config on their machine. We moved to VS2010, and it is now forcing me to add web.config to my project in order to run debug mode. Because our project is linked to TFS, it automatically adds web.config to source control and tries to maintain it that way.

Is there a way to run in debug mode without including web.config in your project? Or is there a better way to manage config files?

Answer 1

Jarrett,

All I have is an anecdote about how we handle the situation.

We have a team of 4 programmers.

We use a source control solution outside of VS -- TortoiseSVN. We each maintain our own local web.config which is included in the project. The project file is included in the repository, but we have the web.config set to "Ignore on commit" status.

I'm not sure what source code control you are using, but subversion with Tortoise SVN (which runs outside of Visual Studio) has worked great for our small team. Most of us program on two separate machines... one at the office, one at home.. so when you couple that with the fact that we have two production servers, we're comfortably dealing with 10 web.config's per project.

With that said, you have to remember to bring over another developer's web.config file when you setup a new development computer, otherwise the solution will either not load properly, or setup a default web.config which does not contain the appropriate connection strings and app settings.

And a final note: We're using IIS 7 for debugging

Answer 2

SO has a good answer for this here .. I havent checked out the multiple web.configs in VS2010 but I wonder if this was added because of the changes they did make to web.conig..

Answer 3

Hi Jarret,

I'm managing a dozen of .NET developers on several ASP.NET projects (with SVN as source control), and I confirm it's a real pain to maintain web.config between them !

Itchi : each developer may want to have his own connection string, informations to get automatic connected to an application, etc.

I solved this by using NANT (http://nant.sourceforge.net) in all our .NET projects, basically :

1) genuine web.config is moved as a template in a subfolder

2) Hard coded values must be remplaced with ${your_property} properties

3) genuine web.config is marked as ignored in SVN

4) each developer create his property file (whose name must include at least the current Windows username), with personal properties

5) a NANT's build file must be created to load the current Windows username property file, then copy the templated web.config to the genuine place (with extended properties)

6) NANT is triggered during the Visual Studio's pre-build, to execute the build file

That's all folk, now each developer can manage it's own property file stored in SVN, independently of the machine it's connected (as long as the Windows username is the same of course)

You can extend this behaviour with the machine name, the current configuration, etc.

Note : altought Microsoft introduced web.config transforms in Visual Studio 2010, there is still not a solution for per developer web.config ?

Answer 4

I have used T4 templates to solve this. Instead of having a web.config, you have a web.tt which generates a web.config. In the web.tt file you can generate different code based on the machinename or the current user.

Answer 5

I haven't seen a good answer for managing different web.config files per developer with TFS to date.

However if the issues that cause developers to require different web.config files are addressed instead, this typically results in better results regardless of the chosen version control system.

For example, less differences between developer environments will reduce Works On My Machine (WOMM) arguments and will often also reduce the configuration changes for environments beyond development (eg Test, Production) which in turn simplifies deployment and reduces annoying environment-configuration-specific bugs.

Depending on the nature of the configuration item, there are usually several different strategies to mitigate per-environment differences. Many of which I suspect already have answers on Stack Overflow.