Managing web.config for teams in VS2010 & TFS

I hope this helps someone. I've used this methodology for the past couple of months now. This is really easy to do. I am using VS 2010 with TFS 2010. Let's break it down:

• All web config files are now "DependentOn" the "web.config"
• Each developer or team needs their own "[User/Team].Debug.config"
• Config files should be transformed regardless if we're "Publishing" in release mode or not.

Here's how it's done:

1. Right-click the Web project you want to do this to and choose "Unload Project" (not "Remove Project").

2. Right-click the same Web project again (should be grayed-out now) and choose "Edit ...csproj". This will open the project in an Xml editor.

3. Scroll down until you find the section that has all the "Web.config" listings. Now, comment out all the "DependentUpon" elements in the Xml.

4. Close the Xml editor and save your changes. Next, right-click on your project again and choose "Reload". When the project reloads, you will notice that the Web.configs no longer "stack" under the "Web.config". This is necessary in order to "trick" TFS.

5. Now, copy the "Web.config" file, paste it in the same project and rename it to "Web.base.config". This is going to be used to re-generate the Web.config each time (covered next).

6. Now, select the Web.config file and go to "File --> Source Control --> Exclude Web.config from Source Control". Also, Open the Source Control Explorer (TFS Explorer view) and find the location of where your Web.config is and delete it from TFS. This is done because the Web.config will get re-generated each time you build the project (which I will cover next).

7. Now, we're going to create a new Build file that will help us regenerate the Web.config for any Built Type, even Debug ones (which is what the Web.config Transformed lacked to begin with). Create a new Xml file in your project and rename it to "[YourProjectName].wpp.targets". It is important to name this exactly what your project is called including all dots, dashes, etc (ex. My.Project.wpp.targets).

8. Now, enter the following Xml into the new file. Do not worry if it starts underlining syntax errors:

   <?xml version="1.0" encoding="utf-8"?><Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">    <UsingTask TaskName="TransformXml"               AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll"/>    <!-- Make sure web.config will be there even for package/publish -->    <Target Name="CopyWebConfig" BeforeTargets="Build;Rebuild">        <Copy SourceFiles="Web.base.config"              DestinationFiles="Web.config"              OverwriteReadOnlyFiles="true"              SkipUnchangedFiles="false" />    </Target>    <Target Name="CustomTarget" BeforeTargets="BeforeBuild">        <Message Text="Transforming: Web.$(Configuration).config" Importance="high" />        <TransformXml Source="Web.base.config"                      Transform="Web.$(Configuration).config"                      Destination="Web.config" />    </Target></Project>

9. Now, from this point on, you NEVER, NEVER edit the Web.config, it will be overwritten every time the app compiles. You only edit the "Web.base.config".

10. Now, let's make the Project look like it was. Right-click the Project again and "Unload" it. Now, right-click again and "Edit" it. Now, go back and un-comment all the Elements we commented out in Step #3. Also, you should add the "DependentOn" element under the "Web.base.config" element so that it will show up under the "Web.config" as well. Close and save it, then reload your project again. You should notice that all the configs are now under the "Web.config" again.

11. At this point, you can add as many Configurations to your Project / Solution as you want. For example, I've added a Build Config called "Tim (Debug)", but the Project config is called "Tim.Debug". When I right click the "Web.config" and choose "Add Config Transforms", it now adds my "Web.Tim.Debug.config" file. You could also add configs per environment or per team.

It's worth noting that your individual config files are only a sub-set of the "Web.base.config" and they will be "Transformed" during any build process. To switch which Transform is going to be built during debugging, just go to the top of your solution and choose which Build Config you want. As long as you have a web.config for that Build Config, it will transform. If not, you'll get the "Web.base.config" instead.

NOTE: This should also work with standard Windows/WPF apps as well using the "app.config" instead.

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.

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