Configuration

The .NET Framework provides a file-based configuration mechanism that gives administrators control over the way .NET applications run, without any need for recompiling the applications. For example, administrators can control:

• which protected resources an application can access

• which version of an assembly an application can use (binding redirection)

• which version of the common language runtime an application should use

• where the common language runtime should search for an assembly

• which channel (TCP, HTTP, etc.) and ports an application should use

• which machine, channel, and port a remote object can be obtained from

• custom application configuration settings

• security permissions that should be granted to an assembly

Based on their usage, the configuration under .NET can be classified as a general-purpose configuration or a security configuration.

General-Purpose Configuration

In Chapter 3, we learned that there are two types of general-purpose configuration files that are available under .NET: One is at the machine level and the other is at the application level. We also learned how some of the tasks mentioned earlier, such as binding redirections, can be performed using these configuration files. We will be covering many aspects of the configuration in the chapters to come. In this section, we look at how the application configuration file can be used to provide custom configuration settings.

Custom Configuration Settings

Application configuration files are good candidates to store custom application settings. The .NET Framework provides a predefined configuration section called appSettings that developers can use to store key–value pairs, as shown in the following example:

<configuration>
  <appSettings>
     <add key="License" value="abracadabra"/>
  </appSettings>
</configuration>

To programmatically access configuration settings, the .NET Framework provides a set of classes and interface under the namespace System.Configuration. Of interest to us is a class, ConfigurationSettings, that lets us read the configuration sections. This class provides a property, AppSettings, that can be used to read the values from the appSettings section, as illustrated in the following code:

// Project CustomSettings

public static void DemoSimpleSettings() {
    String s = ConfigurationSettings.AppSettings["License"];
    if (s != "abracadabra") {
      Console.WriteLine(
        "Please contact your software vendor!");
      return;
    }
    Console.WriteLine("Proceeding...");
}

The predefined section appSettings is useful for storing key–value pairs. If your needs require more than just key–value pairs, then it is possible to define your own sections and the handler code for the sections. For example, you might wish to define an XML tag <owner> that stores the first name and the last name of the product's owner as attributes. An example is shown here:

<owner FirstName="Pradeep" LastName="Tapadiya" />

To be able to process this information, you need to define a configuration section handler class. A configuration section handler class implements a standard interface IConfigurationSectionHandler. Here is the definition for this interface:

interface IConfigurationSectionHandler {
     object Create(object parent, object context, XmlNode node);
}

While reading the configuration, the configuration system calls method Create on the handler associated with a configuration section. This method is required to read the configuration section (passed in as parameter node) and return an object representing the configuration.

The first two parameters to the method Create are meaningful only under ASP.NET; otherwise the configuration system sets them to null. Parameter parent points to the object created by the section handler for the parent web.config if you have multiple web.config files in the hierarchy. Parameter context points to an HttpConfigurationContext object that provides the current ASP.NET context information such as the virtual path to the Web.config file.

Here is the implementation of our section handler:

// Project CustomSettings

public struct Person {
    public String FirstName;
    public String LastName;
}
public class PersonHandler : IConfigurationSectionHandler {
    public object Create(Object parent, object configContext,
        XmlNode section) {
      XmlAttributeCollection attribCol = section.Attributes;

      Person person = new Person();
      person.FirstName = attribCol["FirstName"].Value;
      person.LastName = attribCol["LastName"].Value;
      return person;
    }
}

Our implementation of the method Create simply reads the attributes from the supplied XML node and constructs and returns an object of type Person.

The next step is to let the configuration system know that the <owner> section in the configuration file should be handled by type PersonHandler. This is done by means of the <section> entry in the configuration file. This is illustrated in the following configuration settings:

<configuration>
  <configSections>
      <section name="owner" type="PersonHandler, MyApp" />
  </configSections>

  <owner FirstName="Pradeep" LastName="Tapadiya" />

</configuration>

This configuration indicates that the <owner> section and anything underneath it be handled by the type PersonHandler that is defined in assembly MyApp. Note that the configuration system requires that the <section> entries be grouped under a node <configSections>.

At this point, we are set to read the configuration. This is done by means of a static method, Configuration.GetConfig. The following code excerpt shows how we can read the <owner> section from the configuration file and obtain a Person object:

public static void DemoComplexSettings() {
    Person owner =
      (Person) ConfigurationSettings.GetConfig("owner");
    ...
}

A final word: If XML attributes are what you are interested in reading, as was our case, then you can also use a .NET-defined class SingleTagSectionHandler. You can find a usage example on the companion Web site.

This concludes our introduction to reading custom configuration settings. Check the SDK documentation for more details on custom configuration.

Security Policies

Under .NET, security-related configuration settings are stored under a different file, the security policy file. This file includes security information such as permissions granted to an assembly. We will look at the security configuration settings in a later chapter on security.