appSettings Considered Harmful

Since .NET 1.0, developers have been able to easily dump all manner of settings in the appSettings configuration section. And boy, does it get overused! Ever join a new project and find something like this lurking in the config file?

Yuk!

Here’s the good news: It doesn't have to be this way. In fact, I would go so far as to suggest that there are no longer any good reasons to use the appSettings section. Yay!

Firstly, since .NET 2.0, we have the connectionStrings section, specifically designed for holding database connection strings. Tobin recently posted a nice simple example of how to handle connection strings for multiple developers / environments within a single source-controlled config file.

Secondly, there’s a whole bunch of settings in this example which would be better stored in the database, with administrative users given a front-end to manipulate the values when required. Otherwise, you end up relying on the likes of sysadmins to make changes to business rules, which can be more trouble than it’s worth.

Thirdly, and most importantly – for the remaining properties we can instead choose to use custom configuration sections to hold our settings in an organised, hierarchical way and strongly-typed manner. This is the de facto approach when developing shared class libraries, but is also really valuable for application-specific settings. This is nothing new – here’s a nice succinct blog post from Phil Haack in March 2007 explaining this technique – but in my experience it isn’t used frequently enough.