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

Question

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.

Answer 1

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.

Answer 2

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.