Assumptions

This article assumes some familiarity with the Framework-supplied method of reading application values from the <appSettings> element within the applications configuration file (via the System.Configuration.ConfigurationSettings.AppSettings object) and assumes the reader has some familiarity with the registry.

The Joy of AppSettings

The System.Configuration.ConfigurationSettings.AppSettings object provides easy access to configuration values stored within an application's configuration file. This is typically the 'web.config' for ASP.NET applications and the "App.Config" (actually "YourApp.EXE.Config") for WinForms or console applications. This inbuilt mechanism provides an easy-to-use method of accessing configuration settings and is a recognition of the fact that all applications will typically need to access some form of configuration data, whether it be simple default values or critical operational parameters.

Optionally, an application can define its own custom configuration section within the configuration file; however, this article will be concentrating on the former method. Defining a custom configuration section involves more work on the part of the developer, and, due to the fact it requires considerable customization, it is not applicable to the technique being described here.

One of the issues experienced by developers when using this method (i.e., accessing data via the <appSettings> element within the application cofnguration file) is the fact that accessing the configuration data is performed in a weakly-typed manner. That is, the data accessed is always retrieved as a string, and explicit knowledge of the configuration key used to access the configuration value is required. The simple example below illustrates this.

C#

using System.Configuration;
string itemValue = 
  ConfigurationSettings.AppSettings["itemKey"];

VB.NET

Imports System.Configuration
Dim itemValue as String
itemValue = 
  ConfigurationSettings.AppSettings("itemKey")

In the above example, the "itemValue" variable will contain the configuration value, and the "itemKey" literal string represents the configuration key. If the configuration value actually represents a value other than a string, such as a boolean (true/false) or numeric value, then this must be converted by the calling code each time the configuration value is accessed.

Furthermore, the configuration key must be explicitly known for the call to be successfull. This not only adds extra work on the part of each developer having to access these values, but also introduces potential areas of errors that can be easily introduced into the application.

Making Things Easier

What would be nice is a method of accessing configuration values where we don't have to worry about converting it from its string/textual representation within the configuration file into its actual data type and also not having to worry about the literal text configuration key name to access a particular configuration value.

How about a method of exposing configuration values as strongly-typed properties, allowing for multiple configuration sources and comments that provide easy use when using these properties via Intellisense?

Using static properties that only expose the 'accessor' method and contain full XML style comments will provide this for us. Also, the 'accessor' property method can test to see if the value extracted from the configuration file was successful and, if not, attempt to read the configuration value from another source, such as the registry.

Examine the code segment below. Note: All further code examples will be given in C# due to its native support of XML comments and the advantage this allows for the technique being described.

using System.Configuration;

///<SUMMARY>
///My Test configuration class
///</SUMMARY>
public class TestConfig
{
  private TestConfig() { }
  
  ///<SUMMARY>
  /// Database connection string
  ///</SUMMARY>
  public static string DBConnectionString
  {
    get
    {
      const string KEYVAL = "DBConnectionString";
      const string DEFVAL = "";
      string strVal = 
        ConfigurationSettings.AppSettings[KEYVAL];
      if (strVal == null || strVal == String.Empty)
         strVal = DEFVAL;
      return strVal;
    }
  }
    
  ///<SUMMARY>
  /// Should we enable our fandangled tracing feature
  ///</SUMMARY>
  public static bool EnableTracing
  {
    get
    {
      bool retVal = false;
      const string KEYVAL = "EnableTracing";
      const string DEFVAL = "false";
      string strVal = 
        ConfigurationSettings.AppSettings[KEYVAL];
      if (strVal == null || strVal == String.Empty)
      strVal = DEFVAL;
      if (strVal.ToUpper() == "TRUE")
         retVal = true;  
      return retVal;
    }
  }
}

SqlConnection myConnection = 
  new SqlConnection(TestConfig.DBConnectionString);

if (TestConfig.EnableTracing)
{
   // do some tracing stuff
}

The Benefits

So, what are all the benefits of using this approach? Glad you asked....

1. Strongly-typed method of accessing configuration properties.
2. Full Intellisense support within the Visual Studio.NET IDE.
3. No need to rely on the AppSettings class and know AppSettings key values to retrieve configuration settings from the configuration file.
4. Configuration values can be "massaged" or "altered" prior to returning them to the caller. This can be as simple as returning a default value if no configuration entry is present or more complex manipulations.
5. The configuration file need not be the only source of configuraiton data. For example, if a value does not exist in the configuration file, it can be retrieved from the registry or the database automatically (the demo code generator supplied provides support for this). This has the advantage of being able to use a single configuration class, whether it be from a web application (using Web.Config) or within the same app but as a COM+/Enterprise Services component (and perhaps using the registry). It all looks the same to the caller.
6. Consistent configuration data access for all developers within your team with ability to generate documentation (via XML commenting and auto-documentation features) for your configuration settings class.
7. No class instantiation required because of the use of static members.

So here is something we have prepared earlier....

Accompanying this article is a windows application that generates a static configuration class for you. Its a simple application that allows you to define namespaces, class names, configuration properties with associated configuration entry keys to access the data as well as comments to describe the class and each configuration entry. C# is the only language supportted; however, full source code is provided, so using an easy abstracted design to add your own support for Visual Basic.NET (or any other language if you desire) should be no problem.

In the case of a missing configuration entry, you can elect to have support for reading from a selected registry key to access the same configuration values, all using the same configuration entry defined in the list.

Conclusion

As an application architect and developer, I find this method of accessing configuration data to be very intuitive, particularly in a team of developers who are very used to object oriented programming. This method also provides a good deal of flexibility and consistency in using your applications configuration parameters.