One of the hardest problems to solve when setting up a deployment strategy is how to handle the web.configs and exe.configs. Each environment will have different settings, and so every time you deploy something some where you need to make that web.config look different.
The quick and dirty answer is to have a separate web.config for each environment. Then during a deployment we drop the prod/web.config or staging/web.config into the web directory, and your good to go. However, like a lot of problematic development strategies, this is really fast and easy to get going with, but it doesn’t age very well. What happens when your DEV->STAGING->PRODUCTION environments evolve into LOCAL->DEV->QA->INTEGRATION->STAGING->PRODUCTION? Or when you have machine-specific or farm-specific settings that change from one part of the production environment to another?
Most importantly, what happens when that web.config changes for a reason other than configuration? Then you have a whole bunch of web.configs to fix, and you’re going to put a typo in at least 2 of them, it’s guaranteed.
Let’s take a look at at VERY simple web.config, created from just a basic MVC 4 project:
Zoinks, that is a lot of configuration.
Well, actually, exactly how much “configuration” is there?
Well, actually, the answer is one line:
<add name="DefaultConnection" providerName="System.Data.SqlClient" connectionString="Data Source=(LocalDb)\v11.0;Initial Catalog=aspnet-MMDB.AzureSample.Web-20130117123218;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnet-MMDB.AzureSample.Web-20130117123218.mdf" />
That is the ONLY line that is going to change from environment to environment. Everything else there is not configuration, it’s code.
OK sure, it’s in a “configuration” file. Who cares. It is tied to your code, and it should change about as often as your code changes, not more. It certainly should not change between environments. My general rule is, “if any change to it should be checked into source control, it’s code.” The sooner you stop pretending that they are different in a way that gives you an enhanced level of configuration flexibility, the sooner you’ll be a happier person. Trust me.
The problem here is that the web.config is a confused little person. It does try to configure stuff, but is actually two types of stuff. As far as most people are concerned, it is for configuring their application, but the other 90% of it that they never touch and usually don’t understand is for configuring the underlying .NET and IIS guts, not your application directly. And once you’ve coded your application, that 90% should never change from environment to environment, unless your code is changing as well.
And of course that code does change over time. If you add a WCF web service proxy client to your application, it’s going to fill your web.config up with all sorts of jibber-jabber that you better not touch unless you know what you are doing. But deep inside there is the endpoint URL that DOES need to change from environment to environment.
Again, this is where the “have a web.config for every environment” really breaks down, because now you have to go through and update every one those web.configs to add in all that crazy WCF stuff. And try not to screw it up.
So what’s can we do about it? We have a few options:
One option is to put all of the configuration in the database. This can introduce a lot of issues, when you configure your application to point to database that configures your application, your run into all sorts of codependency issues that makes your systems environments really fragile. The only time I’ve seen this be a good idea is when you have really specific change control rules about not being able to touch configuration files on the server outside of an official deployment, but configuring settings in the database through an administration page would be allowed.
I think these two options are preferable:
- Drop a brand new web.config on every deployment and have your deployment utility and and reconfigure it, either using web.config transformations, XSLT, or a basic XML parser.
- Use the configSource attribute on your settings. This lets you put all of your connectionString or appSettings in different files, which is NOT updated from source control in every deployment. This way you can always drop the latest web.config without having to worry about reconfiguring it. (If you’re using Azure, this goes a step farther, by having a completely separate file for reserved for environment configuration, outside of your web application package)
Both of these options work well. The first option works better if you have only a few options or if you need to update something that does not support a configSource attribute, like a WCF endpoint. The second option works better if you have a whole list of settings and can consolidate them into the connectionStrings, appSettings, etc.
But either way, no matter what, ALWAYS drop a new web.config, and ALWAYS make sure you have a plan to treat YOUR configuration differently than the rest of the web.config.