Using an external configuration source in Web.config
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
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.
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:
Now add a new XML file called ConnectionStrings.xml in the TestConfig folder
and jey in the following markup in it:
<add name="connstr" connectionString=
"data source=.\sqlexpress;initial catalog=
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:
<add key="autoemail" value="email@example.com" />
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:
<add name="connstr" connectionString=
"data source=MYSERVER;initial catalog=
<add key="autoemail" value="firstname.lastname@example.org" />
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:
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
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
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
protected void Page_Load(object sender, EventArgs e)
HyperLink1.NavigateUrl = "mailto:" +
- Here, we used ConfigurationManager class to retrieve the application
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
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
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.
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.