Multiple ASP.NET Configuration Files

Question

I have found a number of pieces of information on having multiple ASP.NET configuration files for a web deployment. However, I am still unsure if I can accomplish what I want to accomplish.

Basically, the website I am working on can be deployed to three different sites. Depending on the site that it is deployed to, the configuration settings need to be changed. What I would like to do is have configuration files for each possible configuration (full web.config files) and then be able to tell a deployment build which config file to use for a particular deployment (I can edit this manually if necessary).

Is there something as simple as pointing to a different .config file, or do I need to do something more sophisticated?

EDIT: One particular concern that I have is that I also need settings in system.net for mail settings, etc. So, I'm not looking to only override the appSettings.

Thanks

Answer 1

Any configuration section - such as <smtp> - can be "externalized", e.g. stored in an external file.

Other than the file= statement on <appSettings> (which is available only for app settings :-() it's not a "additional" setting - you just point your config system to an external file.

So you could have this in your app.config/web.config:

  <system.net>
    <mailSettings>
      <smtp configSource="smtp.test.config" />
    </mailSettings>
  </system.net>

and this in your smtp.test.config:

<?xml version="1.0" encoding="utf-8" ?>
<smtp>
  <network host="smtp.test.com" port="244" userName="test" password="secret" />
  <specifiedPickupDirectory pickupDirectoryLocation="C:\temp\mails"/>
</smtp>

This works as of .NET 2.0 (maybe even 1.x), and it works for every configuration section - but not for configuration section groups like <system.web>.

Of course, you can now create additional config files, like smtp.staging.config and so forth, and now your problem has been reduced to replacing a single line in your web.config.

You can do this using an installation script, a XML preprocessor, or even by human intervention.

It doesn't completely solve the problem as .NET 4 and the web.config transformations hopefully will, but it's a step and a bit of help.