web.config - auto generate a release version

Question

Simple task, but for some reason no simple solution just yet.

We've all got web.config files - and I haven't worked anywhere yet that doesn't have the problem where someone yells across the room "Sh*t, I've just uploaded the wrong web.config file".

Is there a simple way of being able to auto generate a web.config file that will contain the right things for copying to release? An example of these being:

• Swap connection string over to use live database
• Change
• Switch over to use the live/release logging system, and live/release security settings
• (in our case we need to change the SessionState mode to InProc from StateServer - this isn't normal)

If you have others, let me know and I'll update it here so it's easy for someone else to find

Maintaining 2 config files works, but is a royal pain, and is usually the reason something's gone wrong while you're pushing things live.

Answer 1

Visual Studio 2010 supports something like this. Check it out here .

Answer 2

How are you deploying your builds. In my environment, this used to be a pain point too, but now we use cruisecontrol.net and script our builds in nant. In our script, we detect the environment and have different versions of the config settings for each environment. See: http://www.mattwrock.com/post/2009/10/22/The-Perfect-Build-Part-3-Continuous-Integration-with-CruiseControlnet-and-NANT-for-Visual-Studio-Projects.aspx for my blogpost onthe subject of using cruisecontrol.net for build management. Skip to the end fora brief description of how we handle config versions.

Answer 3

In my most recent project I wrote a PowerShell script which loaded the web.config file, modified the necessary XML elements, and saved the file back out again. A bit like this:

param($mode, $src)
$ErrorActionPreference = "stop"
$config = [xml](Get-Content $src)

if ($mode -eq "Production")
{
    $config.SelectSingleNode("/configuration/system.web/compilation").SetAttribute("debug", "false")
    $config.SelectSingleNode("/configuration/system.web/customErrors").SetAttribute("mode", "off")
    $config.SelectSingleNode("/configuration/system.net/mailSettings/smtp/network").SetAttribute("host", "live.mail.server")
    $config.SelectSingleNode("/configuration/connectionStrings/add[@name='myConnectionString']").SetAttribute("connectionString", "Server=SQL; Database=Live")
}
elseif ($mode -eq "Testing")
{
    # etc.
}

$config.Save($src)

This script overwrites the input file with the modifications, but it should be easy to modify it to save to a different file if needed. I have a build script that uses web deployment projects to build the web app, outputting the binaries minus the source code to a different folder - then the build script runs this script to rewrite web.config. The result is a folder containing all the files ready to be placed on the production server.

Answer 4

XSLT can be used to produce parameterized xml files. Web.config being xml file this approach works.

You can have one .xslt file(having xpath expressions).

Then there can be different xml files like 1. debug.config.xml 2. staging.config.xml 3. release.config.xml

Then in the postbuild event or using some msbuild tasks the xslt can be combined with appropriate xml files to having different web.config.

Sample debug.config.xml file can be

<Application.config>
   <DatabaseServer></DatabaseServerName>
   <ServiceIP></ServiceIP>
</Application.config>

.xslt can have xpaths referring to the xml given above.

Can have a look at the XSLT transformation This code can be used in some MSBuild tasks or nant tasks and different web.config's can be produced depending on the input config xml files.

This way you just have to manage the xml files.

There is only one overhead that the xslt file which is similar to web.config need to be managed. ie whenever there is any tag getting added in the web.config the xslt also needs to be changed.

Answer 5

I don't think you can 100% avoid this.

The last years of work ever and ever shows: where human worked, there are fails.

So, here are 3 ideas from my last company, not the best maybe, but better then nothing:

1. Write an batch file or an C#.Net Application that change your web.config on a doubleclick
2. Write a "ToDo on Release"-List
3. Do pair-realesing (== pair programming while realease :))