Some ASP.NET 2.0 Configuration Tips

Illustrates some common techniques for managing web.config sections across multiple deployments and modes for ASP.NET 2.0 Web applications.

 It is a common scenario for ASP.NET Web developers to want to have different sets of configuration data depending on whether the project is being developed locally within Visual Studio in Debug mode, being tested in QA in Release mode, or is in Release mode in production. Also, settings may differ from machine to machine if the Application is deployed into a web farm scenario.

 There are several ways to enhance the ability to maintain separate sets of configuration data; the typical environment is one where we have a number of settings in the web.config that will rarely be changed, and some others that we do want to be able to have changes based on what mode and what location the application is being run from.

 The simplest technique, and one that is workable in a majority of scenarios, is to use the "file=" attribute of the appSettings section:

<appSettings file="myCustomAppSettings.config" >
   <add key="one" value="this will be overwritten by the same key in the external file" />
  </appSettings>

  //(myCustomAppSettings.config file:)

<appSettings>
<add key="one" value="this will replace the key in the main web.config with the same name" />
  <add key="two" value="this is from the external file" />
</appSettings>

NameValueCollection coll= ConfigurationManager.AppSettings;
    Response.Write("<b>appSettings Section:</b><BR/>");
     foreach(string key in coll.AllKeys)
         { 
             Response.Write(key +": "+coll[key] +"<br/>");
         }

Any settings in the web.config appSettings section that aren't replaced by the external definitions because of having the same key name will appear first in the collection.

With this arrangement, you can have a separate "myCustomAppSettings.config" file in each deployment, and when the web.config is deployed, this file is left alone. So, each deployment location can have one of these that will always contain different items without fear of copying a debug web.config into a production deployment and destroying required items and values.

Other standard sections can also be read directly from web.config with the use of an external file. For these you would use the configSource attribute:

<connectionStrings configSource="externConnectionStrings.config" />

//(externConnectionStrings.config file:)
<connectionStrings>
 <add name="conn1" connectionString="Note that the localSqlServer shows up because it is defined in web.config (machine.config) and we did not use the clear or remove directives" providerName="SqlClient" />
</connectionStrings>

ConnectionStringSettingsCollection cnColl = ConfigurationManager.ConnectionStrings;
    foreach(ConnectionStringSettings set in cnColl)
        {
            Response.Write(set.Name + ": "+set.ConnectionString +"<br/>");
        }

Finally, you can create a custom configuration "appSettings" section of your choice using the System.Configuration.AppSettingsSection class:

In the web.config:

<configSections>
      <section name ="states" type="System.Configuration.AppSettingsSection,System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> 
</configSections>


    <states file="states.config" >
        <add key="Arizona" value="AZ" />
    </states>
    <system.web>
    ...

<states>
<add key="New York" value ="NY" />
<add key="Massachusetts" value="MA" />
</states>

string configPath = HttpContext.Current.Request.CurrentExecutionFilePath;
  configPath = configPath.Substring(0, configPath.LastIndexOf('/'));
      if (configPath.Length == 0) configPath = "/";
         Configuration myRootConfig = WebConfigurationManager.OpenWebConfiguration(configPath);
         AppSettingsSection myAppSettings = myRootConfig.GetSection("states") as AppSettingsSection;
         KeyValueConfigurationCollection myColl = myAppSettings.Settings;
         foreach(KeyValueConfigurationElement elem in myColl)
            {
                Response.Write(elem.Key +": "+elem.Value +"<br/>");
            }

Note that with this arrangement, it is possible to have multiple web.config files at various locations on the filesystem. Provided that the correct path is supplied to the configPath variable as above, that is the web.config that will be loaded and processed.  This provides for a lot more "custom" flexibility at the expense of a bit more complicated code.

The WebConfigurationManager class in the System.Web.Configuration namespace is the main programming point that allows for custom manipulation of configuration data. It includes static methods to retrieve application settings and connection strings.  It works much like the ConfigurationManager class but is oriented toward web applications.

The GetSection static method takes an XPath expression to indicate the section you want to get, and allows you to cast the resulting object to a strongly typed reference for built-in section types.  For example, here is how one can read the <identity... section:

IdentitySection section;
 section = WebConfigurationManager.GetSection("system.web/identity") as IdentitySection;
    if (section != null)
    {
       Response.Write("Identity: Impersonate = " + section.Impersonate);
    }