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, lets examine this minimal web.config with an appSetting entry to hold our connection
string:
1 <?xml version="1.0" encoding="utf-8" ?>
2 <configuration>
3
4 <system.web>
5 <compilation defaultLanguage="c#" debug="true" />
6 </system.web>
7
8 <appSettings>
9<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
10 </appSettings>
11
12 </configuration>
To read the key we use the ConfigurationSettings class from the System.Configuration namespace, as
shown below.
12 private void Page_Load(object sender, EventArgs e)
13 {
14 string connectionInfo = ConfigurationSettings.AppSettings["ConnectionInfo"];
15 using(SqlConnection connection = new SqlConnection(connectionInfo))
16 {
17
connection.Open();
18
19
// perform work with connection
20
21 }
22 }
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 applicationwide to being a per-user configuration item kept in the Session or in a cookie.

Encapsulation
Lets abstract away the source of the connection string using a class with a static property.
1 using System.Configuration;
2
3 namespace aspnet.config
4{
5 public class Configuration
6 {
7
public static string ConnectionInfo
8
{
9
get
10
{
11
return ConfigurationSettings.AppSettings["ConnectionInfo"];
12
}

13
14
}
15 }
16 }
Now our Page_Load method looks like the following.
11 private void Page_Load(object sender, EventArgs e)
12 {
13 using(SqlConnection connection = new SqlConnection(Configuration.ConnectionInfo))
14 {
15
connection.Open();
16
17
// perform work with connection
18
19 }
20 }
The changes we made to the above code were relatively small - but powerful. Now the Page_Load function
doesnt 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.
Youll 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, lets 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. Lets change our web.config
to look like the following.
1 <?xml version="1.0" encoding="utf-8" ?>
2 <configuration>
3 <system.web>
4 <compilation defaultLanguage="c#" debug="true" />
5 </system.web>
6
7 <appSettings file="testlabsettings.config"/>
8
9 </configuration>
Next, we can create the external file testlabsettings.config and add an appSettings section with our connection
information.
1 <appSettings>
2 <add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
3 </appSettings>

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.
Youll 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.