Avoid app Settings Usage in Controls or Shared Libraries
Date Published: 28 July 2008
Since .NET 1.0, there has been a built-in appSettings section in configuration files. Many developers use this space to store application settings, such as the name of the site or (before
Personally, I avoid using appSettings even for my own application configuration settings. Why? Because it really is too stinking easy to create your own custom configuration section, and this provides a much more readable and strongly typed way to access the values your application needs. AppSettings might be ok for a quick spike of a site where you’re not doing anything “the right way” out of some desire for expediency, but otherwise it should be avoided. There are two reasons why I feel this way.
Global Scope and Naming Collisions
AppSettings is basically a global variable collection. There is nothing to prevent two separate control vendors from using the same key for their appSettings variable names. In practice this doesn’t happen very often because vendors are smart enough to use long names (for the most part) that include their company and/or product name in them. However, this could easily be avoided (due to its being unnecessary) if a company- or product-specific configuration section were used instead.
Organization and Clarity
The second and arguably more applicable reason to avoid overusing appSettings for shared components is organization and clarity. There is zero discoverability of configuration options available within appSettings. The only way to figure out what is available to configure is the documentation. Further, once several different vendors’ settings are intermingled in appSettings (along with a variety of actual site-specific settings), it can be quite a mess and quite long. This can result in errors when changes are made to the configuration settings.
Favor Custom Configuration Sections for Controls and Shared Code
Default configuration options should be distributed with the control in a self-contained section, making it easy for users to see the default values. Updates to the configuration file can then be as simple as cut-and-paste since the section is self-contained – there is less risk of the user screwing up the configuration instructions because they’re trying to edit an already crowded and disorganized appSettings section in the configuration file.
Steve is an experienced software architect and trainer, focusing currently on ASP.NET Core and Domain-Driven Design.