Web Application Settings in ASP.NET 2.0
page 1 of 1
Published: 14 Apr 2006
Unedited - Community Contributed
ASP.NET 2.0 brought about a number of improvements in the way configuration settings are stored and accessed. Several new configuration sections have been added to the web.config schema, settings can be updated via code, and can be more easily encrypted and decrypted than before. In this article, Richard examines these new features with the help of code samples.
by Richard Dudley
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 136702/ 45


Before .NET there were a number of ways a web application's settings could be used.  One of the most common methods was to declare all settings in one file and include that file on every page that needed the settings.  This method had its drawbacks, as did the use of the application variables, database storage and other methods of storage.

With .NET came the web.config file and the ConfigurationSettings class.  Developers could add settings to the web.config file as key-value pairs in an <appSettings> block.

Listing 1

<add key="ConnString" value="server=(local);database=pubs;uid=;pwd=;"/>

Settings could be retrieved as such:

Listing 2

MyConnectionString = ConfigurationSettings.AppSettings("ConnString")

This was a great improvement, but still had its drawbacks.  The settings were loosely typed and there was no Intellisense, so a developer had to remember or double-check a setting's key.  If more than a key-value pair was required, entire sections could be added to the web.config, but they required a custom handler to be written.  Settings could also be stored in external configuration files, but these also required custom handlers, and as such, were not commonly used.  Also, settings were stored in plain text and anyone reading the settings file could potentially gather information they should not have.  Settings could be encrypted, but that meant writing code to encrypt and decrypt the settings.  Plus, encryption keys were not easily migrated between different machines.  The difficulty often prevented the use of encryption.

In Visual Studio 2005 and .NET 2.0, Microsoft has made some great enhancements, both in how configuration information can be accessed and how this information can be used.  Since storing connection strings was very common, new sections (including a ConnectionString section) were added to the web.config schema and these sections can be encrypted and decrypted natively.  All settings can be managed easily at design time through Visual Studio 2005 tools.  A new ConfigurationManager class has been added to the framework, which provides a convenient way to get and set configuration properties at run time.  Settings can also be easily placed in external configuration files and still managed with the configuration tools.  Whew!  That is a lot of good stuff--let's get started!  One note though, although we are focusing on ASP.NET web applications, all of these improvements and more are available in Windows forms applications. 

Getting Started

One of the first decisions you will need to make is where to store the settings.  In a web application, you only want to store application settings in your configuration files; user settings are best stored by using the Profile provider.  This is because user settings can not be feasibly separated into individual My Documents folders, like they can with a Windows application.


Settings which are not likely to change very often, such as connection strings, can be stored in the web.config file.  Since .NET 2.0 now allows your code to easily write configuration settings, it is possible to update your web.config at runtime (by using an admin tool you created).  However, changes to the web.config will cause an application restart each time you write to this file and you obviously do not want to do this very often.  Instead, you want to use an external configuration file to store settings that will be updated.

A new property of the configuration section elements has been added in .NET 2.0 - configSource.  You use configSource to specify the name of the external file containing that section's settings, such as the following:

Listing 3

<appSettings configSource="appsettings.config"/>

Note: For security reasons, it is a good idea to give your settings files a .config extension, since files with this extension will not be served to the Internet.

When you specify a file using configSource, you must put all of that section's settings in the external file.  If you only specify a file by using the older 'file' property, the settings in the external file will be merged with the settings in the web.config file.

The structure of the external file must replicate that of the section it is replacing.

Listing 4

<add key="MySetting" value="ValueOfMySetting"/>

Using configSource does not completely solve the problem of application restarts when the file is updated.  To prevent application restarts when your configuration file is updated, you need to do a little editing in your machine.config file (this is probably not an option if you are on a shared host).  Find your machine.config file, usually found in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG, and make a backup copy- just in case if you mess up with the original file.  Open the file and locate the section element for the configuration section you need to modify.  It will look similar to Listing 5 below (line breaks added to fit this format).

Listing 5

<section name="appSettings"type="System.Configuration.AppSettingsSection,
System.Configuration, Version=,Culture=neutral, 
requirePermission="false" />

The restartOnExternalChanges setting needs to be set to false.  If the section tag does not include this attribute, you can add it.  The appSettings by default is already set to false, but other configuration sections may not be.  Changing the machine.config will cause applications to restart, so try to make all changes at once.

New Configuration Sections

As mentioned above, several new configuration sections have been added to the web.config schema.  These sections can be placed in external files using the configSource property, just as with appSettings.  These new sections include:




Lists connection strings, as built using the new management tools described below.


Stores information about site map providers.


Stores information about membership providers.


Stores settings used by the SMTP service, including server name, default From and Subject values.

A complete list of new and updated configuration sections can be found in the .NET SDK by searching for "new configuration sections" (the .NET SDK can be downloaded from http://asp.net).  The important thing to note is that we are no longer limited to using the appSettings section.  We have several specialized sections to suit our needs and the information in these sections can be encrypted.

Setting Values at Design Time

The .NET 2.0 Framework includes two management tools which can be used to create and change application settings.  One tool is a web-based tool with limited functionality and the other is an MMC snap-in with greater functionality.

The Website Administration Tool can be launched from within Visual Studio 2005 by navigating Website >> ASP.NET Configuration.  The built-in web server will start and the administration tool will be launched.

Figure 1: Web Site Administration Tool

In addition to application settings, you can also configure providers, such as the Membership provider, and set up security settings (such as new website users or roles).  In this article, we will only be looking at the Application settings tab.  This tool allows us to create and edit settings in the appSettings section.

Figure 2: Application Settings Tab

To create new application settings, click on the "Create Application Settings" link.  On the next page, enter the setting's name (which will be the key in our web.config), the value and click Save.  After our web.config is updated, we will be given the option of adding another setting or returning to the Applications settings tab.

Figure 3: Creating a New Application Setting

If we configured an external settings file using configSource, our new setting is saved in that file. Otherwise, our new setting is saved in the web.config file.

Figure 4: New Setting Stored in External File

Clicking the "Manage application settings" link allows us to edit or delete settings.  Note that the key cannot be changed, only the value.

Figure 5: Editing an Application Setting

The MMC snap-in is installed as part of the IIS control panel (not found in XP Home Edition) and is launched by:

1.      Drill down the Control Panel >> Administrative Tools >> Internet Information Services.

2.      Expand the local computer node.

3.      Expand Web Sites node to obtain a list of websites.  On a Windows 2000 or XP, you will have to expand the Default Web Sites to obtain a list of all the subwebs on your system.

4.      Right-click on the web whose settings you wish to change and select Properties.

5.      Select the new ASP.NET tab (see Figure 6).

Figure 6: The ASP.NET Control Panel

Clicking the "Edit Configuration" button opens the ASP.NET Configuration Settings tool.  Settings created with the Configuration strings manager become part of the connectionStrings section; Application Settings become part of appSettings.  As you can see, this tool allows us to control a great deal more of the application than the Website Administration Tool, but we are only interested in this tab.

Figure 7: Editing MySetting


Retrieving Values at Run Time

All the added application setting sections and improved functionality led to the addition of a new class--the WebConfigurationManager class (link to documentation in References).  In its simplest use, the WebConfigurationManager allows us to read settings from appSettings and connectionStrings in a single line of code.

Listing 6

Dim MyString as String = WebConfigurationManager.AppSettings("MySetting").ToString

Other sections can be read by using the GetSection method.  Some sections have specific class, including the Pages section (PagesSection) and connectionStrings section (ConnectionStringSettings class).  Custom settings sections will use the ConfigSection base class.

As an example, if we want to list all of the namespaces in the Pages section, we could use code, such as:

Listing 7

Protected Sub Page_Load(ByVal sender As Object, ByVale As System.EventArgs) Handles Me.Load
Dim MyString As String
Dim pagesSection As PagesSection
Dim i As Integer
pagesSection = CType(WebConfigurationManager.GetSection("system.web/pages"),PagesSection)
For i = 0 To pagesSection.Namespaces.Count - 1
  MyString + = pagesSection.Namespaces(i).Namespace"<br />"
Label1.Text = MyString
End Sub

Setting Values at Run Time

Some applications are built with administration tools that can update the application's settings.  In ASP.NET 2.0, we can modify settings in the web.config in our code.  This is something we would want to do in response to a button's click event.  The sample code below shows how easy it is to modify an application setting in ASP.NET 2.0.

Listing 8

Protected Sub btnUpdateSetting_Click(ByVal sender AsObject, ByVal e As System.EventArgs) _
 Handles btnUpdateSetting.Click
Dim cfg As Configuration
cfg = WebConfigurationManager.OpenWebConfiguration("~")
Dim setting As KeyValueConfigurationElement = _
If Not setting Is Nothing Then
  setting.Value = "New Value Setting"
End If
End Sub

Encrypting Configuration Settings

Most sections of the web.config can be encrypted, but there are a few things you need to think about before you do this.  Unfortunately, there is no visual tool that will encrypt configuration settings; our two choices are either the command-line tool aspnet_regiis or by using code.  There are also two encryption algorithms (RSA and DPAPI), each with its own considerations.

With either algorithm, the keys can be stored at the machine level or at the user level.  If you run a server with only your applications on it, and there is not an issue with all settings being encrypted with the same key, then machine storage would work.  If you need to ensure all your applications' settings are encrypted with different keys, ensure that each application runs in its own application pool and each pool has its own identity.  Then you will need to pick the user storage for the keys.

Microsoft's Patterns and Applications Group has good examples using DPAPI or RSA (links are in the references).  Each of these articles discusses the merits of each algorithm and should be considered required reading in addition to this article.  One particular advantage that RSA has over DPAPI is that the RSA keys can be exported to an XML file and then copied to other machines.  This is especially useful for developers who can create RSA keys on a production server then export and copy them to test and development machines, so configuration settings do not need to be encrypted in each environment.

In brief, we encrypt configuration sections, such as the following:

Listing 9

aspnet_regiis -pe "<config section>" -app"/<application name>" -prov "<providername>"

For instance, if we wanted to use RSA to encrypt the appSettings section in MyApplication, we would issue the following command.

Listing 10

aspnet_regiis -pe "appSettings" -app"/MyApplication"

Since RSA is the default provider, we do not need to specify the encryption provider.  If we wanted to do the same thing with DPAPI, we would issue the following command.

Listing 11

aspnet_regiis -pe "appSettings" -app"/MyApplication" -prov "DataProtectionConfigurationProvider"

If you are on a shared host, you probably cannot execute command-line utilities and you definitely want to use the user store.  Your only option to encrypt your configuration settings is to use code in your application.  David Hayden (link in references) has a good example in C#; the VB.NET translation is below.

Listing 12

Protected Sub btnEncryptSettings_Click(ByVal senderAs ObjectByVal e As System.EventArgs) _
Handles btnEncryptSettings.Click
Dim config As Configuration =WebConfigurationManager.OpenWebConfiguration("~")
Dim section As ConfigurationSection =config.GetSection("appSettings")
If Not section Is Nothing And Notsection.SectionInformation.IsProtected Then
End If
Dim MyString As String
MyString =WebConfigurationManager.AppSettings("MySetting").ToString
Label1.Text = MyString
End Sub

When we deploy our application, we do not want encryption code hanging around.  Ideally, this part of the example will be part of a separate project that is deployed with the production application.  The encryption page is then loaded and then deleted from the production server.  The production application is already set to use the configured settings.

The really good news is, after we have encrypted our configuration settings, we do not need to write any code to decrypt the settings.  ASP.NET automatically decrypts the settings when they are read.


The .NET 2.0 Framework brought about many improvements, including a new class to manage web application settings.  The WebConfigurationManager class adds support for encrypted sections, as well as new sections, and the ability to update settings from within an application.


ASP.NET Quickstart Tutorial, "Using the Management API", http://www.asp.net/QuickStart/aspnet/doc/management/mgmtapi.aspx

Channel 9, " How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA", http://channel9.msdn.com/wiki/default.aspx/Channel9.HowToEncryptConfigurationSectionsUsingRsaInAspNet20?diff=y

Esposito, D., "Introducing Microsoft ASP.NET 2.0", 2005, Microsoft Press.

Hayden, D., "Encrypt Connection Strings AppSettings and Web.Config in ASP.NET 2.0 - Security Best Practices", http://davidhayden.com/blog/dave/archive/2005/11/17/2572.aspx

Meier, J.D., et al., "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI", http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGHT000005.asp

Meier, J.D., et al., "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA", http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGHT000005.asp

MSDN Library, "PagesSection Class", http://msdn2.microsoft.com/en-us/library/system.web.configuration.pagessection(VS.80).aspx

MSDN Library, "WebConfigurationManager Class", http://msdn2.microsoft.com/en-us/library/ms151430.aspx

Schofield, S., "ASPdot.NET: Create Export & Encrypt connection string on server and dev machine with ASP.Net 2.0", http://www.aspdot.net/articles/encryptedconnstring/

User Comments

Title: read appsetting form webconfig   
Name: Ramavtar rajput
Date: 2010-07-26 6:01:46 AM
foreach (string key in ConfigurationManager.AppSettings)
string value = ConfigurationManager.AppSettings[key];
dd.Items.Add(new ListItem(key, value));
Title: Gud Work..   
Name: Saaju
Date: 2010-02-23 12:31:00 AM
your article is really useful. i learn t one useful stuff today. Thanks for sharing information with public members
Title: Incredibly Useful!   
Name: Nathon Dalton
Date: 2010-02-22 7:03:13 PM
Bravo! You were incredibly thorough in this article and I just wanted you to know how incredibly useful this will be to me! You have saved me a tremendous amount of time and I greatly thank you for it!
Title: appreciating   
Name: mohamed
Date: 2009-09-01 5:15:54 AM
thank you , this was realy helpful
Title: HHHeelllo   
Name: Kushal
Date: 2008-11-04 12:40:42 AM
thanks for ur help
Title: encryption of webconfig   
Name: John
Date: 2008-03-24 8:00:47 AM
Hi All

Thanks for your reply and advice.

My problem is that if someone can log into the server via
an FTP program (I use WS_FTP), then the web.config is
easily viewable with no restrictions.

The encryption schemes you mentioned are to deny people
access via a web browser? I will look into hashed
passwords, but if someone gets into my site via an FTP
program, does this encryption do anything?

Title: Config.Save Problem   
Name: Mike
Date: 2007-06-08 12:39:30 PM
After saving changes with config.save() all comments and formating is removed from external Appsettings.config file.

Is there a way round this?

Title: Add AppSettings key/ value pairs dynamically   
Name: Balakrishnan.S
Date: 2007-01-31 1:52:53 PM
Can anybody help me How to add AppSettings Key / Value pair dynamically using C#
Title: Doesn't solve anything ..   
Name: Dave Griffiths
Date: 2006-10-09 8:48:12 AM
The problem with using the AppSettings as you said at the beginning of your article is that they are not strongly typed and have no intellisense. Your article doesn't show how these are overcome in .NET 2.0.

To overcome these, you need to use the new "Application Settings" property page on a project .. These are added to a new section handler "applicationSettings" and values are both strongly typed and add intellisense (in the My.Settings namespace in VB - haven't tried in C#), although they are a lot more complex in the web.config than appSettings.
Title: Web Application Settings in ASP.NET 2.0   
Name: Lori Wypych
Date: 2006-08-01 1:18:25 PM
I am running the website starter kit that comes with VS 2005. The first step is to create an admin user using the asp.net configuration tool. However, when I run it I get a timeout error which says to restart the tool. Below is the error:
As a security measure, the Web Site Administration Tool times out after a period of inactivity. Changes to machine.config or web.config may also result in the tool needing to be restarted. To continue configuring your web site, restart the tool.
If you know how to correct this error, please email me at lwypych@taisoftware.com as I don't even know where your answer would be posted. I've been searching many forums now and nothing.
Title: Merging of Config Items   
Name: Rich Dudley
Date: 2006-07-05 11:58:49 AM
Hey Joe,

You can also use Web Deployment Projects to change some sections of the web.config as your project is built for different configurations. Check out http://www.rjdudley.com/blog/Use+Web+Deployment+Projects+To+Replace+Webconfig+Sections.aspx.
Title: Optional Merging of config items   
Name: Joe Manning
Date: 2006-06-12 8:55:13 AM
Thanks Rich, I think that is what I'll have to do.
Title: Merging of Config Items   
Name: Rich Dudley
Date: 2006-06-12 6:23:31 AM
I see what you're saying. Would it be possible to bake your defaults into different configSource files, and just swap the files using MS Build when you go to deploy?
Title: Optional Merging of config items   
Name: Joe Manning
Date: 2006-06-09 2:20:42 PM
Yes they all have the configSource attribute, however configSource operates differently than the original file attribute. I actually liked the old file attribute implementation better for two reasons:
One, you didn't need to account for every item in the section, you could just override the config items specific to that deployment.
Second, the referenced external file was not a required element, therefore you could bake you web.config with all the default values and if there were no external file present on that deployment the app would run with those default values.

I'm trying to duplicate this pattern in 2.0 and due to this new configSource design, I'm not able to.
Title: Overrides in External COnfigs   
Name: Richard Dudley
Date: 2006-06-09 11:15:19 AM
The file attribute has been deprecated in favor of the configSource, which I think all the new sections support (at least the ones I tried).
Title: Optional Merging of config items   
Name: Joe Manning
Date: 2006-06-09 9:35:38 AM
Great article Richard!

I would like to provide default values in the base web config file and allow overrides in the external configs. In 1.1 I did this with the file attribute on the appSettings sections (which I believe is still available), however none of the newer sections allow this attribute. Any suggestions?
Title: Great Help   
Name: Jessy Ezzy
Date: 2006-04-28 7:55:30 PM
Thanks for the article, I needed to know how to update key values in the appsettings section, I just googled it and your article was the first match in the result, didn't expect it to be that easy and now I know how to encrypt them too.
Title: Web App Settings   
Name: Chuck Snyder
Date: 2006-04-28 6:07:01 PM
Thanks. Have searched before for reading settings from Web.config, but this was very clear and easy to work with. Made a hard job quite easy.
Title: Using .NET 1.1   
Name: Richard Dudley
Date: 2006-04-21 9:55:32 AM
Unfortunately, this is a new feature in ASP.NET 2.0, and is not easily replicated in ASP.NET 1.1. You really have to write everything yourself, and store the information in external XML files or a database.

If you only need to read custom settings, you could try this article: http://aspnet.4guysfromrolla.com/articles/053102-1.aspx.
Title: Mr.   
Name: Partha Majumdar
Date: 2006-04-21 3:10:49 AM
Dear Sir,

I have always had this question regarding how the Configuration could be saved for an ASP application. We could do this when we used to write applications using PowerBuilder. This article provides mechanism which are similar to what we used to use. Also, the section regarding encrypting the configuration file is very useful.

However, we are presently working with ASP.Net 1.1 and many of our applications are developed using this tool. Can you suggest a mechanism how this feature can be implemented using ASP.Net 1.1.

Thanks in advance.

Title: Connection String in DAL   
Name: Richard Dudley
Date: 2006-04-16 7:10:11 PM
That's a very good question. Decryption is inherent to the functioning of the framework, so if your DAL can retrieve the connection string, it should be able to decrypt it automatically. I used the DAAB, not a custom DAL, which requires you to pass in a connection string or a connection object from your code. Sorry I don't have a better answer--I haven't tried that. I'll blog when I get a chance to work that out.
Title: Encrypting Configuration Settings   
Name: Bilal Haidar [MVP]
Date: 2006-04-16 2:32:03 PM
Hello Richard:
I want to congratulate you for this article.

I always had a questoin about connectionStrings in web.config:
I have tested once encrypting the connectionString section, then used a GridView with an SqlDataSource and worked just fine with the connectionstring being encrypted. My analysis was that, when the SQLDataSource wanted to use the connectionString to access the database, it checked first if the connectionString is encrypted or not and worked accordingly.
What if I am using the connectionString in my data access layer, do I need such checking (if it does exist)? Or shall I get the connectionString decrypt it first then use it?

I couldn't find an accurate answer up till now.

I also wanted to add Scott Mitchell's article on the encryption issue. http://aspnet.4guysfromrolla.com/articles/021506-1.aspx


Product Spotlight
Product Spotlight 

Community Advice: ASP | SQL | XML | Regular Expressions | Windows

©Copyright 1998-2017 ASPAlliance.com  |  Page Processed at 2017-01-21 2:39:06 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search