Using an external configuration source in Web.config

Introduction

Real world web applications are developed, tested and configured at various levels. For example, developer of the application will use and test it on his own workstation. Later on the testing team will test it on their test servers. There might be management presentations at which stage the same application is hosted on a temporary server. Finally, when the application is complete it is hosted in the production environment. During this entire process the configuration file (web.config) continuously undergoes changes in terms of database connection strings, membership, role and profile provider information and application settings. Changing the web.config file each and every time is tedious and error prone. For example, somebody may forget to change the database connection string and end up modifying data from production database instead of test database. Fortunately, ASP.NET 2.0 comes with a neat feature that allows developers to isolate different sets of configuration settings and then link them inside the web.config file. This reduces the chances of error because the modification required to the configuration file is much less as compared to the previous scenario. This article explains how to use configuration information stored in external files and reduce the mess of managing multiple configurations.

The problem description

Often developers need to maintain different sets of configuration - one that is used during development, one that is used during testing, one that is used in production environment and so on. This becomes necessary because many of the configuration parameters are different under each environment. For example, the databases that are used during development, testing and production environments might be different. In ASP.NET 1.x developers often used to change the web.config file directly. This approach poses several problems such as:

• You need to change many settings in the web.config file itself
• Developers may forget to switch all the settings to correct values leading to problems and data corruption
• You need to give write access to web.config to all the people involved in developing, testing and administrating the web site
• Whenever you change web.config file your application is going to restart itself. They is no control on this behavior

The above problems can be minimized (though can not be completely avoided) with the help of the new feature of ASP.NET 2.0 that allows you to load configuration sections from external files. This is done using the configSource attribute of configuration sections. Let's see how.

Sample Application

In order to demonstrate the use of this feature we will develop a simple web site consisting of two web forms - Login.aspx and Default.aspx. The former acts as a login page and also allows users to register with the web site. The later simply displays a list of customers from Northwind database in a GridView.

Creating XML files containing configuration sections

First of all create two folders in the web site - TestConfig and ProdConfig. We will store test configuration files in the TestConfig folder and production configuration files in the ProdConfig folders respectively.

We need to isolate the following configuration elements:

• <connectionStrings>
• <appSettings>
• <membership>

Now add a new XML file called ConnectionStrings.xml in the TestConfig folder and jey in the following markup in it:

<connectionStrings>
<add name="connstr" connectionString=
"data source=.\sqlexpress;initial catalog=
northwind;integrated security=true" 
providerName="System.Data.SqlClient"/>
</connectionStrings>

This is a normal <connectionStrings> section that you would have added in the web.config file but we are storing it in an external XML file called ConnectionStrings.xml. The name of the XML file can be anything but it is a good idea to give it the same name as that of the configuration section.

Similarly add AppSettings.xml and Membership.xml files and add the following markup to them:

<appSettings>
<add key="autoemail" value="someone@somedomain.com" />
</appSettings>

<membership defaultProvider="Northwind">
<providers>
<add name="Northwind" 
type="System.Web.Security.SqlMembershipProvider" 
connectionStringName="connstr"/>
</providers>
</membership>

Here, we added an application setting called autoemail that we will use on our web form later. We pointed the membership provider to the Northwind database so that all the user information will be stored in it. Note that we have stored the connection string "connstr" in a separate file called ConnectionStrings.xml.

Note: It is assumed that you have configured Northwind database using ASPNET_REGSQL.EXE tool to support membership features.

On the same lines add same set of files in the ProdConfig folder. This time they will contain different settings as shown below:

<connectionStrings>
<add name="connstr" connectionString=
"data source=MYSERVER;initial catalog=
MYDB;integrated security=true" 
providerName="System.Data.SqlClient"/>
</connectionStrings>

<appSettings>
<add key="autoemail" value="me@mydomain.com" />
</appSettings>

<membership defaultProvider="MyMembershipProvider">
<providers>
<add name="MyMembershipProvider" 
type="System.Web.Security.SqlMembershipProvider" 
connectionStringName="connstr"/>
</providers>
</membership>

Linking to XML files from web.config

Now open the web.config file. We will first test the application by pointing the various configuration sections to the files from TestConfig and then from ProdConfig. Modify the web.config as shown below:

<?xml version="1.0"?>
<configuration>
<appSettings configSource="TestConfig\AppSettings.xml"/>
<connectionStrings 
configSource="TestConfig\ConnectionStrings.xml" />
<system.web>
<membership 
configSource="TestConfig\Membership.xml"/>
<compilation debug="true"/>
<authentication mode="Forms"/>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</configuration>

Note the markup in bold. Each of the section contains an attribute called configSource. The configSource attribute is used to point to an external file that will be supplying the configuration section. For example, <appSettings> section is supplied by AppSettings.xml file from TestConfig folder and so on. Note that we have set authentication mode to "Forms" and denied access to all the anonymous users using <deny> tag.

Next, we will develop the two web forms to test the working of the configuration file.

In order to develop the Login.aspx you can follow these steps:

• Add a new web form to your web site caled Login.aspx
• Drag and drop a Login and CreateUserWizard control
• Set DestinationPageUrl property of Login control to "~/default.aspx"
• Set ContinueDestinationPageUrl property of CreateUserWizard control to "~/login.aspx"

The Figure 1 shows Login.aspx in the browser:

Figure 1: Login.aspx in the browser

In order to develop the Default.aspx you can follow these steps:

• Add a new web form called Default.aspx (if it doesn't exists)
• Drag and drop an SQL Data Source control and configure it to select CustomerID and Company columns. Note that the wizard  automatically shows "connstr" as the connection string name (Figure 2)

Figure 2: Configure Data Source wizard

• Drag and drop a GridView control and set its DataSourceID property to SqlDataSource1

• Drag and drop a HyperLink control and add the following code in the Page_Load event

protected void Page_Load(object sender, EventArgs e)
{
HyperLink1.Text = 
ConfigurationManager.AppSettings["autoemail"];
HyperLink1.NavigateUrl = "mailto:" + 
ConfigurationManager.AppSettings["autoemail"];
}

Running and testing the sample application

Run the web site. It should take you to Login.aspx. Create a new user account and sign in with the same user id. Once you signed in successfully you will see Default.aspx as shown in Figure 3.

Figure 3: Sample run of Default.aspx

You will find that the new user is created in the Northwind database because the configSource attribute of <membership> tag points to Membership.xml file which in turn is configured to store data in Northwind database. Now change configSource attribute of all the elements to point to corresponding files from ProdConfig folder and run the web form. This time it picks up configuration sections as defined by various files in the ProdConfig folder.

You can now compare the amount of change that you would have done in traditional method and the new configSource approach.

Changes to external configuration files

Whenever you make any change to web.config the ASP.NET application is restarted. The same behavior is observed when you change any of the external files mentioned in the configSource attribute. The good part is that you can modify this default behavior. In the machine.config file you will observe an attribute called restartOnExternalChanges which is set to true by default for almost all the sections (<appSettings> is an exception). This attribute controls whether the application is restarted (true) or not when the external file changes. As a caution use this attribute with care and with the understanding of implications.

Summary

Managing different sets of configuration settings can be neatly done in ASP.NET 2.0. The new configSource attribute allows you to point web.config to external file that supplies the section configuration. Moreover you can also control the restarts of the application when such external file is changed.