Bean Software

.NET Tutorials

Configuring Windows Application

In this article we will discuss about configuration files, types of configuration files and their internal schema and settings.

Configuration Files

Configuration files are XML files that contain configuration settings for applications. Configuration files are used to change application settings without recompiling the applications. They can also be used to set machine policies that affect how applications run on a computer. Configuration files can be modified whenever required.

Format of a Configuration file

Configuration files contain a hierarchy of elements that specify configuration information. A sample configuration file is given below:

The <configuration> element is the root element in every configuration file used by the common language runtime and .NET Framework applications.

A configuration file uses tags to mark the beginning and end of an element. For example, the <runtime> element has a beginning tag specified as <runtime> and an end tag as </runtime>. An empty element however has a start tag but no end tag. Within the beginning and ending tags of an element there may be any number of child elements. The start tag of an element may contain one or more attributes. An attribute is specified using a name/pair. You make configuration settings by specifying appropriate values for attributes in an element's start tag.

Types of Configuration Files

There are three types of configuration file:

- Application configuration file
- Machine configuration file
- Security configuration file.

Application Configuration Files

They contain configuration settings specific to applications. These files provide a way of overriding the metadata in assemblies without having to rebuild the application.

When you execute an application, the Common Language Runtime (CLR) searches for dependent files, e.g. assemblies and resource files, that the application needs for execution. This process is also known as probing. During the probing process, the CLR searches for the application configuration file and examine it to determine the settings contained in it. The probing behavior is then modified depending on the configuration settings. For example, settings in the application configuration file can redirect an application to look for an assembly in a different folder. The new assembly however, must be built with the same key pair that the application expects.

The name of an application configuration file is the name of the application with a .config extension. An application called myapp.exe will have configuration file called myapp.exe.config. Also, this file will be located in the same directory as myapp.exe.

Machine Configuration Files

Machine Configuration Files include settings that apply to an entire computer. The name of machine configuration file is machine.config. The location of this file is:

%SystemRoot%\Microsoft.NET\Framework\<Version>\CONFIG\

Machine Configuration Files are useful when a component is used by multiple applications. In that case, it is easier to put the settings for that component in a single machine configuration file rather than creating separate application configuration files for different applications. By default the settings in the machine configuration files, override the settings in the application configuration files.

Security Configuration Files

Security configuration files contain information about permission sets and code group hierarchy. Theses files contain information related to code access security system. You can configure these files to modify the security policy. However, manual editing of security configuration files is not recommended. Rather you can use the .NET Framework Configuration tool (Mscorcfg.msc) or the Code Access Security Policy tool (Caspol.exe) to make these changes. Using these tools ensures that policy changes do not corrupt the security configuration files.

Configuring Applications

One can change the way an application runs by changing the application settings in the application configuration file. For this, you need to understand its elements.

Elements in an Application Configuration File:

ELEMENT	DESCRIPTION
<configuration>	This is the root level element in configuration file and indicates that the information included in this tag is used to configure the application. Each configuration file must contain exactly one <configuration> element.
<runtime>	This element is a child level element of the <configuration> element and contains information about assembly binding and garbage collection
<supportedRutime>	This element is a child level element of the <runtime> element. It specifies the version of the common language runtime that an application supports.
<gcConcurrent>	This element is a child level element of the <runtime> element. It specifies whether the common language runtime runs garbage collection on a separate thread.
<assemblyBinding>	This element is a child level element of the <runtime> element. It contains all information about assembly version redirection and the locations of assemblies.
<dependentAssembly>	This element is a child level element of the <assemblyBinding> element. It includes binding policy information such as name, version and location of an assembly. If binding policy is needed for multiple assemblies, a separate <dependentAssembly> element must be used for each assembly.
<assemblyIdentity>	This element is a child level element of the <dependentAssembly> It includes information used to identify an assembly.
<bindingRedirect>	It is a child level element of the <dependentAssembly>. It redirects one assembly version to another.
<codeBase>	This element is a child level element of the <dependentAssembly> element. It specifies where the runtime can find a strong named assembly.
<probing>	This element is a child element of the <runtime> element and specifies the applicationâ€™s base directory subdirectories of the applicationâ€™s base directory that the runtime should search when locating an assembly.
<publisherPolicy>	It is child of <dependentAssembly> or <assemblyBinding>. It specifies whether the runtime applies publisher policy to your application. When placed in <dependentAssembly it will apply to specifc assembly, while in other case it will apply to all assemblies referred by the application

Some configuration elements include attributes that provide additional details to the runtime. The following table lists these attributes:

ELEMENT	ATTRIBUTE	DESCRIPTION
<supportedRutime>	version	The version that .NET Framework supports
<gcConcurrent>	enabled	It can have value true or false. A true value indicates that garbage collection is concurrent and a false indicates that it is not concurrent.
<assemblyIdentity>	name	The name of the assembly.
	publicKeyToken	A hexadecimal value that specifies the strong name of the assembly.
	culture	String that specifies the language and country/region of an assembly.
<bindingRedirect>	oldVersion	The version of the assembly that was originally requested.
<bindingRedirect>	newVersion	The version of assembly to use instead of the originally requested version.
<codeBase>	Version	The version number of the assembly which <codeBase> applies to.
<codeBase>	Href	The URL where the assembly is stored.
<probing>	privatePath	The location of the subdirectories of the applicationâ€™s base directory that might contain assemblies.
<publisherPolicy>	Apply	This attribute can have a value of yes or no and specifies whether or not to apply publisher policy.

Working with Application Configuration Files

Some areas where application configuration files can be useful are given below:

- Specifying the runtime version
- Specifying the concurrent garbage collection
- Specifying the location of an assembly
- Redirecting assembly versions
- Creating a publisher policy.

Specifying the Runtime Version

This can be done by using the <supportedRuntime> element. For example:

Specifying the concurrent garbage collection

Specifying the location of an assembly

The location of an assembly can be specified using <codeBase> or <probing> element

The <codeBase> element specifies where the runtime can find a strong named assembly.

The runtime locates assemblies that do not have a code base by probing. The <probing> element specifies subdirectories of the application's base directory that the runtime should search when locating an assembly.

Example:

Redirecting assembly versions

When you build an application against a specific version of a strong-named assembly, the application uses that version of the assembly at run time. However, at times you want the application to run against a newer version of an assembly. You can use the <bindingRedirect> element to redirect one version of any assembly to another. For example:

Creating a publisher policy

When a component vendor releases a new version of an assembly, the vendor can include a publisher policy so applications that use the old version now use the new version.

You can use the <publisherPolicy> element to specify whether the common language runtime applies publisher policy.

You can specify whether to apply publisher policy in the application's configuration file for either a specific or all assemblies the publisher uses.

1. To specify whether to apply publisher policy for a particular assembly, put the <publisherPolicy> element in the <dependentAssembly> element.

2. To specify whether to apply publisher policy to all assemblies the application uses, put the <publisherPolicy> element in the <assemblyBinding> element.

Configuration sections

Till now we have discussed configuration settings that the common language runtime reads when an application is executed.

A configuration file can also contain information that the application reads at run time. You can specify this information in configuration files by using configuration sections.

The .NET Framework provides several predefined configuration sections (e.g. <appSettings> and developers can also create custom configuration sections.

Configuration sections have two parts:

1. Configuration section declaration.
2. Configuration settings.

You can put Configuration section declarations and configuration setting in the machine Configuration file or in the application Configuration file.

Configuration Settings are read by section handlers at run time. Section handlers are classes that implement the IconConfigurationSectionHandler interface.

A Section handler first reads settings in the machine Configuration file and then in the application Configuration file. Depending on the section handler, either the settings in the application file override the settings in the machine file or the settings form both are merged.

The .NET framework uses the following section handler.

Handler

DESCRIPTION

NameValueSectionHAndler

Returns a name/value pair of configuration settings

IgnoreSectionHAndler

Ignores all elements in the section.

DictionarySectionHAndler

Returns a key-value pair of configuration settings.

SingleTagSectionHAndler

Returns a hash table containing name/value settings.

Configuration Section declarations are made up in the <configSections> element. A new configuration section is created by declaring it in a <section> element inside the <configSections> element. The <section> element has two prorperties:

Name: name of the element that contains the information the section handler reads.
Type: name of the section handler that reads the information.

Now that we have discussed the structure of a configuration section, let us discuss how to use predefined <appSettings> configuration section and how to create custom configuration section.

<appSettings> Section

The following example shows the declaration of the appSettings section as it appears in the machine configuration file.

The following example shows how to make an application setting in a configuration file using the predefined appSettings section:

Application settings defined in the <appSettings> section can be accessed by using the ConfigurationSettings.AppSettings property. The following example shows how to retrieve the application name defined in the above configuration file:

Public Sub readSettings()
    Dim app_name As String
    app_name = ConfigurationSettings.AppSettings("Application name")
    MessageBox.Show("Name of the application is :" & app_name)
End Sub

Custom Configuration Sections

You can also declare configuration sections of your own. The syntax of configuration setting depends on the section handler that is associated with configuration section.

For example, to declare a custom section that uses the SingleTagSectionHandler class, the syntax is:

You can use the static method ConfigurationSettings.GetConfig in the System.Configuration namespace to access configuration settings from an application.

Imports System
Imports System.Collections
Imports System.Configuration

    Public Class MyConfigReader

        Public Sub readConfigSettings()
            Dim values_table As IDictionary
            Dim s1 As String
            Dim s2 As String
            Dim s3 As String

            Values_table=CType(ConfigurationSettings.GetConfig(â€œsampleSectionâ€),
                        _IDictionary)
            s1 = CType(value_table("settings1"), String)
            s2 = CType(value_table("settings2"), String)
            s3 = CType(value_table("settings3"), String)
        End Sub
    End Class

In the above code, the ConfigurationSettings.GetConfig method returns a value of type Object. You must cast Object returned from ConfigurationSettings.GetConfig to an IDictionary object type, which represents a collection of key-value pairs.

The set of key-value pairs is stored in the variable values_table. Each value in values_table must be converted to a String object.

Tutorial toolbar: Tell A Friend | Add to favorites | Feedback