ASP.NET provides a configuration system we can use to keep our applications flexible at runtime. In this article we will examine some tips and best practices for using the configuration system for the best results.

The <appSettings> element of a web.config file is a place to store connection strings, server names, file paths, and other miscellaneous settings needed by an application to perform work. The items inside appSettings are items that need to be configurable depending upon the environment, for instance, any database connection strings will change as you move your application from a testing and staging server into production.

As an example, let’s examine this minimal web.config with an appSetting entry to hold our connection string:

To read the key we use the ConfigurationSettings class from the System.Configuration namespace, as shown below.

Some applications will duplicate these lines of code in many places. If we think about how the above code will evolve over time, we might see a handful of weaknesses. First, we have a hard coded string in place to fetch connection information from the web.config. Hard coded strings can be easy to mistype and difficult to track down if the key ever changes. Secondly, the code will tie us forever to the appSettings section of the web.config file. Although web.config is designed for just such a setting, we might find in the future that we need to pull configuration settings from a database, or change a setting from being application-wide to being a per-user configuration item kept in the Session or in a cookie.

Encapsulation

Let’s abstract away the source of the connection string using a class with a static property.

Now our Page_Load method looks like the following.

The changes we made to the above code were relatively small - but powerful. Now the Page_Load function doesn’t know where the connection string comes from. We could easily change the ConnectionInfo property to retrieve the string from a different source without modifying any other code in the application. We also no longer have to remember the key string and hard code the string at various points in the application. Instead, we can utilize Visual Studio Intellisense when accessing the Configuration class to find the setting we need. The key value only appears once – inside the ConnectionInfo property – so we could again change the key name in the web.config and have only one line of code to update.

Of course this approach only works if all of the code in the application goes to the Configuration class instead of directly to web.config to retrieve settings. For each appSetting entry added to web.config we would add a corresponding property to the Configuration class.

Another advantage to this approach becomes apparent if we have an application setting that is not a string, but a date, integer, or other primitive type. In this case we could have the corresponding Configuration property parse the string from the web.config file and return the appropriate type.

You’ll notice we provided a read-only property for ConnectionInfo. The web.config file is not designed for constant updates. When an ASP.NET application launches a watch is put on the web.config file. ASP.NET will detect if the web.config changes while the application is running. When ASP.NET detects a change it will spin up a new version of the application with the new settings in effect. Any in process information, such as data kept in Session, Application, and Cache will be lost (assuming session state is InProc and not using a state server or database).

Next, let’s take a look at a little known feature of appSettings that can give us even more flexibility.

Multiple File Configuration

The appSettings element may contain a file attribute that points to an external file. Let’s change our web.config to look like the following.

Next, we can create the external file ‘testlabsettings.config’ and add an appSettings section with our connection information.

If the external file is present, ASP.NET will combine the appSettings values from web.config with those in the external file. If a key/value pair is present in both files, ASP.NET will use the value from the external file.

The feature demonstrated above is useful when you keep user-specific or environment-specific settings in the external file. Let web.config contain those settings that are global to all the installed instances of your application, while each user or installed site contains their own settings in an external file. This approach makes it easier to move around global web.config changes and keep web.config checked into source control, while each developer can get their own settings separate.

One caveat to this approach is that the ASP.NET runtime does not detect when the external file changes. You’ll need to make changes to web.config itself for ASP.NET to launch a new version of the application with all changes in effect.

I hope this article has given you some tips on using the appSettings section with the maximum amount of flexibility. To see the source code to additional best practices for configuration handling, download the Enterprise Library.