Different configuration files for development and production in ASP.NET application

On a project I’m working on we have a web application with three configuration files;
Web.Config
Web.Config.TestServer
Web.Config.LiveServer

When we release to the test server, Web.Config is renamed to Web.Config.Development and Web.Config.TestServer is renamed to Web.Config, making that configuration active for the application.

It is quite onerous keeping three very similar configuration files up to date, and this system is used across a number of applications which are part of this project; not just the website.

The differences in configuration are most commonly local directories or paths, URLs, IPs, port numbers, and email addresses.

I’m looking for a better way.

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

While your approach seems tedious, I find it to be the best approach.

I used to keep all of my configurations in a single web.config file, and simply had the “production” section commented out.

Shortly after this I had to do a “hybrid” test where my lookup data was coming from the production server, but the new data was being inserted into the test database. At that point I had to start piece-mealing what parts of the configuration block to comment/uncomment, and it became a nightmare.

Similarly, we have our server administrators do the actual migration from test to production, and most of them aren’t fluent enough in .NET to know how to manage the web.config files. It is far easier for them to simply see a .test or .prod file and migrate the proper one up.

You could use something like a database to store all your configurations, but then you’re running into another layer of abstraction and you have to manage that on top of things.

Once you get the knack or the template of how your two (or three) configuration files will be setup, it becomes a lot easier to manage them and you can have your test server configuration get modified for some unique testing without much hassle.

Method 2

If you have a db server in the mix, you can create a table that has the config, the property name, and the property value in it, then all you have to do is change one value in the web.config, the config name (dev, test, prod).

If you have different dbs for each config, then the only thing that’s different is the connection string.

Method 3

Use Config Transformation and there is a blog here about it.

http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx

Basically you create targets named web.{build configuration}.config. In each target file you write your transformation where you can add, delete and modify nodes and attributes. Example could be

web.staging.configss

<?xml version="1.0"?> 
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> 
     <connectionStrings> 
        <add name="personalDB" 
          connectionString="Server=StagingBox; Database=personal; User Id=admin; password=StagingPersonalPassword" 
          providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)" /> 
        <add name="professionalDB" 
         connectionString="Server=StagingBox; Database=professional; User Id=professional; password=StagingProfessionalPassword" 
         providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)"/> 
       </connectionStrings> 
</configuration>

You then execute the transform by calling MSBuild {project file} /t:TransformWebConfig /p:Configuration=Staging

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0