In .NET, there are generally two types of information in config files: application-specific and environment-specific. The problem with this setup, though, is managing changes to configuration parameters; it's up to the developer to remember to update config files for each environment.

Fortunately, parameters can be easily overridden using the configSource element in web.config, eliminating the need to manually change files for each deployment, not to mention reducing the risk of having to recreate a config file after accidentally overwriting one. Of course, we're talking about software development here, where the simplest solution is often ignored.

B. B. worked with a large client, maintaining code written by their team's developers. And since their developers were sick of "hard coding values in config files," or as I call it, "using config files for their intended purpose," they created their own solution. Rather than XML-based files, they'd use compiled assemblies containing all configuration values. The classes they created weren't static, either; they'd have to be instantiated to read configuration values.

To store, for instance, a mail server name the .NET way:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
	<appSettings>
		<add key="MailServerName" value="mail.somerandomcompany.com" />
	</appSettings>
</configuration>

However, the company decided that this way made more sense:

using System;

namespace Company.Applications
{
    public class RegistrationSite
    {
        private readonly string _mailServerName = "mail.somerandomcompany.com";
        public string MailServerName
        {
            get { return _mailServerName; }
        }
    }
}

Changing the mail server name in the first example would require the following:

  1. Check out the latest version from source control,
  2. change the mail server,
  3. test,
  4. check the change in, and
  5. deploy the file.

Changing the mail server name in the second example requires the developer to

  1. get the latest version of all project files from source control,
  2. find the file containing the MailServerName parameter,
  3. change the value,
  4. compile,
  5. test,
  6. run unit tests,
  7. check the file back in, and
  8. deploy.

In this case, though, the file would need to be deployed across several applications, as this was the central configuration store.

So there you have it; a shining example of a common trend in software development. Solving a problem that doesn't exist with the worst possible solution.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!