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

Answer 1

Here a solution for web.config files and Visual Studio 2010:

1) Edit manually your web application .csproj file to add an AfterBuild Target like this:

  <Project>
   ...
    <Target Name="AfterBuild">
      <Copy SourceFiles="web.config" DestinationFiles="obj\$(Configuration)\tempweb.config" />
      <TransformXml Source="obj\$(Configuration)\tempweb.config"
                  Transform="web.$(USERNAME).config"
                  Destination="obj\$(Configuration)\tempweb2.config" />
      <ReadLinesFromFile File="obj\$(Configuration)\tempweb2.config"><Output TaskParameter="Lines" ItemName="TransformedWebConfig"/></ReadLinesFromFile>
      <ReadLinesFromFile File="web.config"><Output TaskParameter="Lines" ItemName="UnTransformedWebConfig"/></ReadLinesFromFile>
      <Copy Condition=" @(UnTransformedWebConfig) != @(TransformedWebConfig) " SourceFiles="obj\$(Configuration)\tempweb2.config" DestinationFiles="web.config" OverwriteReadOnlyFiles="True" />
    </Target>
  </Project>

This target will transform the Web.config file corresponding to the current developer logged in - hence the $(USERNAME) variable -, with the corresponding file created in 1). It will replace the local Web.config only if the content has changed (to avoid restart) at each build, even if the local Web.config is source controlled, that's why there is the OverwriteReadOnlyFiles is set to True. This point in fact is arguable.

2) Create a file named Web.[developer windows login].config for each developer in the project. (for example in the following screenshots I have two developers named smo and smo2):

These files (1 per developer) can/should be source-controlled. They should not be marked as dependent on the main Web.config because we want to be able to check them out individually.

Each of this file represent a transformation to apply to the main Web.Config file. The transformation syntax is described here: Web.config Transformation Syntax for Web Application Project Deployment. We reuse this cool Xml file transformation task that comes out-of-the-box with Visual Studio. The purpose of this task is merge Xml elements and attributes instead of overwriting the whole file.

For example, here is a sample web.[dev login].config that changes a connection string named 'MyDB', regardless of the rest of the Web.config file:

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
    </connectionStrings>
</configuration>

Now, this solution is not perfect because:

• after building, developers may have a different Web.Config locally than in the source control system
• they may have to force local write when getting a new Web.Config from the source control system
• developers should not check out/in the main web.config. It should be reserved to few people.

But at least, you only have to maintain a unique main web.config plus one transformation file per developer.

A similar approach could be taken for App.config (not web) files but I did not elaborate further.

Answer 2

How about ignoring the file, so it never gets checked in? I've run into a similar issue and have added web.config to the ignore list in Subversion.

In TFS though, it's a little bit harder, see this post on how to do it.

Answer 3

One way you could cope is to have a tokenised system and use a rake script to change the values.

A more rudimentary method could be to have a link to an AppSettings.config file for all AppSettings in your web.config (similar with connections) i.e.

<appSettings configSource="_configs/AppSettings.config" />

Then have a folder with each of your developers have a version in a sub folder (i.e. /_configs/dave/). Then when a developer is working on their own code they copy from the sub folder to the root of the linked folder.

You will need to make sure you communicate changes to these files (unless you tokenise). If you keep the AppSettings.config file out of source control and only check in the devs individual folders (all of them) then they will be forced to copy the correct one.

I prefer tokenisation but can be tougher to get up and running if this is only meant to be a quick fix.