Alternatives to web.config files in ASP.NET

Question

In my experience, web.config files are widely reviled. In particular, I have found them difficult to manage when you have multiple environments to support, and fiddly to update due to the lack of validation at update-time and the verbosity of XML.

What are the alternatives?

Answer 1

I personally don't mind Web.Config for small one-off applications, but for anything substantial I avoid using them for application configuration.

Here's what I do...

• I define one or more interfaces for my configuration depending on the complexity.
• I create different implementations per environment (dev, stage, prod, etc.)
• I use an abstract base class to define common configuration.
• I then use Ninject for dependency injection so the appropriate implementation is provided depending on which environment I am targeting.
• I always code to the configuration interfaces and benefit from compile time checks.

Here's an example...

// Config Contract
public interface IWebAppConfig
{
     string SmtpHost { get; }
     string RootUrl { get; }
}

// Define Common Config Values (values that don't change per environment) 
public abstract class AbstractWebAppConfig : IWebAppConfig
{
     public string SmtpHost { get { return "smtp.google.com"; } }
     public abstract RootUrl { get; }
}

// Dev Config Settings
public class DevWebAppConfig : AbstractWebAppConfig
{
     public override string RootUrl { get { return "http://localhost:1322"; } }
}

// Stage Config Settings
public class StageWebAppConfig : AbstractWebAppConfig
{
     public override string RootUrl { get { return "http://stage.mysite.com"; } }
}

// Prod Config Settings
public class ProdWebAppConfig : AbstractWebAppConfig
{
     public override string RootUrl { get { return "http://www.mysite.com"; } }
}

Advantages of this approach:

• Type Safe
• Configuration is represented as objects not key value pairs (useful for passing logical groupings of config values instead of multiple values)
• Easier to Unit Test classes that are dependent on configuration values
• Sharing configuration across multiple apps is trivial
• Deploying the assembly that contains the configuration implementations will trigger a recycle of the application pool, much like re-deploying a web.config.

You may still use the web.config to define the environment, which is what I usually do by adding the following to the appSettings:

<appSettings>
     <!-- accepts: dev|stage|prod -->
     <add key="Env" value="dev" />
</appSettings>

Alternatively, it could be machine based by using Envrionment Variables, or some other construct.

Answer 2

How long has ASP.NET been in existence; how many production web sites are using it?

They're almost all using web.config, as it comes, out of the box. They can't be "reviling" it too much.

That said, look at the new features of ASP.NET in .NET 4.0, including configuration-specific web.config files, and xml-based transformations of web.config that permit environment-specific web.config versions to be generated at deployment time.

You may revile that a little less.

Answer 3

I strongly disagree with your assertion that web.config files are "widely reviled." In my experience, they're easy to maintain and manage, and in some cases are the only place you can put configuration data.

It's worth noting that VS2010 supports per-build configuration web.config transforms. I have a web.config, web.debug.config, and web.release.config. The debug and release files override the connection strings specified in web.config and replace them with the correct strings, for my debug and production SQL Servers, specifically. I'm also using this to make some AppSettings values config-specific.

Since you can add a build config for as many different targets or configurations as you require, I don't see why you'd feel the need to reinvent the wheel by devising another repository.

That said, you can use just about any repository for whatever data you want to store. A database, text config file of the format of your choice, encrypted image, or what have you.