SP.NET applications usually rely on two of the standard sections in a Web.config
file: the <appSettings>
section that holds general configuration and application values, and the <connectionStrings>
section specialized for storing connection details for data providers such as database servers.
However, custom configuration sections are useful when an application requires complex sets of configuration data. The .NET configuration system can both expose and automatically validate these. It is easy to create custom configuration sets and the related classes that expose this data.
When it comes to actually managing configuration values, the common approach is to simply update and deploy the Web.config
file to all servers running the application. However, the ASP.NET configuration system provides no central mechanism for controlling the values in a Web.config
file, which means thatif you're running multiple servers, such as a Web farmthe Web.config files can become unsynchronized. For example, local operators can change values in Web.config
on specific machines.
Fortunately, Group Policy provides a mechanism for centrally managing features of the operating system and the applications that run upon it. You can take advantage of Group Policy to create a mandatory and centrally managed environment for configuration settings for your Web applications by creating a custom Group Policy Object (GPO) and building Group Policy awareness into your configuration code.
In these articles, you will see an example of using a custom configuration section and a Group Policy aware configuration system. Of course, you can create Group Policy aware code that reads configuration information from the <appSettings>
sections of Web.config
using the technique shown in these articles. Alternatively, as demonstrated, you can combine the custom configuration provider and Group Policy aware techniques so that the configuration classes that expose the custom configuration information are themselves Group Policy aware.
Custom Configuration Sections
You can use the standard <appSettings>
sections of Web.config to provide configuration information for ASP.NET applications and Web services. For generic settings specific to your application, you can populate the <appSettings>
section with a series of <add>
elements that specify a particular setting name and its value:
<add key="myFirstValue" value="2" />
<add key="mySecondValue" value="five" />
You then access these settings through the AppSettings
collection of the WebConfigurationManager class:
// in C#:
Int32 firstValue = Int32.Parse(
String secondValue =
' in Visual Basic.NET:
Dim firstValue As Int32 = Int32.Parse( _
Dim secondValue As String = _
However, there is no facility to map these settings to a specific schema. Therefore, the configuration system cannot automatically verify the presence or absence of a value, or validate the type. In addition, you must cast the returned values to the required types, because the AppSettings
collection does not expose the values as specific .NET types.
If you instead create a custom configuration section and a corresponding handler, you can expose configuration data to your applications as a series of optional or required typed values, and have the configuration system automatically confirm the presence of required values, check for the correct data types, and validate the actual values.