At the root of the inheritance model is the machine.config file (located in the systemrootMicrosoft .NETFrameworkversionNumberCONFIG folder, or systemrootMicrosoft .NET Framework64versionNumberCONFIG for 64-bit machines), which defines configuration settings for the entire system. All configuration files inherit from this file and can override these settings.

Web applications are configured via the web.config file. This file can be located in a number of locations, depending on the scope to which the settings need to be applied. To apply a configuration to all web applications on a machine, place the web.config file in the same directory as the machine.config file. In most cases the settings need to be applied at a much finer granularity. As such, the web.config file can also be placed in any virtual directory or subdirectory to control web applications at that level. If it is placed in the root folder for a web site, the configuration will be applied to all ASP.NET applications in that web site.

A word of caution: When you are working with virtual directories that do not align with the directory structure on the computer, it's possible to have an application that has different configurations depending on how it is referenced. For example, consider C:inetpubwwwrootMainApplicationContactsContact.aspx, which has been set up with both MainApplication and Contacts as virtual directories. You can reference the contact page as either:

http://localhost/MainApplication/Contacts/Contact.aspx

or:

http://localhost/Contacts/Contact.aspx

In the first case, the configuration settings that are applied are inherited from the MainApplication folder and may be overridden by a configuration file in the Contacts folder. However, in the second case, settings are applied only from the configuration file within the Contacts folder.

Windows applications can be configured via an application configuration file, which also inherits from machine.config. Because the output assembly name is known only when an application is compiled, this file starts off as app.config and is renamed to application.exe.config as part of the build process. For example, an application with AccountingApplication.exe as the main executable would have a configuration file entitled AccountingApplication.exe.config. This configuration file is automatically loaded based on its name when the application is loaded. If an app.config files is added to a dll, it will be renamed to assembly.dll.config during the build process.

In conjunction with the application configuration files are a number of security configuration files. These also follow an inheritance path but across a different dimension. Instead of being application-focused, the security configuration files are broken down into enterprise (Enterprisesec.config), machine (Security.config), and user (Security.config). The enterprise- and machine-level files are both stored in the same location as the machine.config file, whereas the user-level file is stored under the user-specific application data folder.

IIS7 changes the way configuration information is stored to use a set of configuration files that work in parallel with those for ASP.NET and the .NET Framework. Because IIS and the .NET Framework are versioned independently, configuration information specific to the individual technologies are held in the machine.config/web.config and the applicationHost.config files, respectively. However, because there is an interrelationship between IIS and ASP.NET, the applicationHost.config file does fit into the configuration file inheritance hierarchy. Because the applicationHost.config file is specific to an instance of IIS, it fits into the inheritance hierarchy after both the machine.config and web.config files located at the machine level (that is, located in the systemrootMicrosoft .NETFrameworkversionNumberCONFIG folder).

The applicationHost.config file can be found in the systemrootSystem32InetSrvConfig folder, and the corresponding schema files can be found in the Schema subdirectory. There are also administration.config and redirection.config files in this folder that are responsible for IIS feature delegation and configuration file redirection, respectively.

Configuration files can be customized to contain any structured XML data. In order to do this, you must define a custom section in the configurationSections block within the configuration file. This defines both the name of the configuration section and the class that is to be called in order to process the section.

The configurationSections section in the machine.config file defines the handlers for each of the standard configuration sections discussed here. You can define your own configuration sections in your application configuration file so long as you specify which class will be used to validate and process that section. For example, the following code snippet defines the section handler for the ConfigurationApplication.My.MySettings configuration section, along with the corresponding section. The schema of this section must correspond to what the System.Configuration.ClientSettingsSection class expects, rather than the normal configuration file schema.

<configuration>
<configSections>
<section name="ConfigurationApplication.My.MySettings"
                 type="System.Configuration.ClientSettingsSection,
System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
                 requirePermission="false" />
</configSections>
.
<ConfigurationApplication.My.MySettings>
<setting name="PrimaryServer" serializeAs="String">
<value>www.builttoroam.com</value>
</setting>
</ConfigurationApplication.My.MySettings>
</configuration>

It is also possible to include configSections in a sectionGroup element that can be used to help lay out configuration information. The preceding example can be extended as follows:

<configuration>
<configSections>
<sectionGroup name="applicationSettings"
                      type="System.Configuration.ApplicationSettingsGroup,
System, Version=2.0.0.0, Culture=neutral, PublicKeyToken= b77a5c561934e089" >
<section name="ConfigurationApplication.My.MySettings"
                     type="System.Configuration.ClientSettingsSection,
System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
                     requirePermission="false" />
<section name="ReferencedAssembly.My.MySettings"
                     type="System.Configuration.ClientSettingsSection,
System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
                     requirePermission="false" />
</sectionGroup>
</configSections>
.
<applicationSettings>
<ConfigurationApplication.My.MySettings>
<setting name="PrimaryServer" serializeAs="String">
<value>www.builttoroam.com</value>
</setting>
</ConfigurationApplication.My.MySettings>
<ReferencedAssembly.My.MySettings>
<setting name="SecondaryServer" serializeAs="String">
<value>www.peaksite.com</value>
</setting>
</ReferencedAssembly.My.MySettings>
</applicationSettings>
</configuration>

Where used, the configSections element must appear as the first child of the configuration element.

The startup configuration section determines the version of the framework that is either required (requiredRuntime) or supported (supportedRuntime) by the framework. By default, a .NET application will attempt to execute using the same version of the framework on which it was built. Any application being built with support for multiple versions of the framework should indicate this with the supportedRuntime element, defining the most preferred framework version first:

<configuration>
<startup>
<supportedRuntime version="v4.0.20409"/>
<supportedRuntime version="v2.0.50727"/>
<supportedRuntime version="v1.1.4322"/>
</startup>
</configuration>

This configuration section would be used by an application that has been tested for versions 4.0, 2.0, and 1.1 of the .NET Framework. Anomalies were detected in the testing for version 1.0 of the .NET Framework, so it has been omitted from the supportedRuntime list. The version number must correspond exactly to the installation directory for that framework version (for example, version 4.0 of the .NET Framework typically installs to C:WINDOWSMicrosoft.NETFrameworkv4.0.20409).

Garbage collection is a feature of the .NET Framework that distinguishes it from non-managed environments. The process of collecting and disposing of unreferenced objects is usually done in parallel with the main application on a separate thread. This means that the user should not see any performance issues as a result of this process being run. However, there may be circumstances when this process should be run inline with the main application. The runtime section of the configuration file can be used to provide limited control over how the .NET runtime engine operates. Among other things, you can specify whether the garbage collection should be done concurrently with the main application.

This section can also be used to specify a location in which to search for assemblies that may be required by an application. This attribute can be useful if an application references assemblies that are in a non-standard location. The following code illustrates the use of the codeBase attribute to locate the ImportantAssembly.dll, as well as to dictate that garbage collection be done inline with the main application thread:

<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="ImportantAssembly"
                              publicKeyToken="32ab4ba45e0a69a1"
                              culture="neutral" />
<codeBase version="2.0.0.0" href="./ImportantAssembly.dll"/>
</dependentAssembly>
</assemblyBinding>

<gcConcurrent enabled="false"/>
</runtime>
</configuration>

The remoting section of the configuration file can be used to specify information about remote objects and channels required by the application. For example, the default HTTP channel can be directed to listen to port 8080 by means of the following configuration snippet:

<configuration>
<system.runtime.remoting>
<application>
<channels>
<channel port="8080" ref="http"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>

Because of the current demand for more secure operating environments, organizations often use proxies to monitor and protect traffic on their networks. This can often result in applications not functioning correctly unless they have been configured to use the appropriate proxies. The networking section of the configuration files can be used to adjust the proxy that an application uses when making HTTP requests.

The .NET Framework ships with an SmtpClient class that can be used to send mail from within an application. Obviously, doing this requires information such as the server and the credentials to use when sending mail. Although such information can be hard-coded within an application, a more flexible approach would be to specify it in a configuration file that can be adjusted when the application is deployed. The following configuration snippet illustrates the use of the default proxy (although it bypasses the proxy for local addresses and the DeveloperNews web site) and specifies the default SMTP settings to be used by the SMTP client:

<configuration>
<system.net>
<defaultProxy>
<proxy usesystemdefaults="true"
                   proxyaddress="http://192.168.200.222:3030"
                   bypassonlocal="true" />
<bypasslist>
<add address="[a-z]+.developernews.com" />
</bypasslist>
</defaultProxy>
<mailSettings>
<smtp deliveryMethod="network">
<network host="smtp.developernews.com"
   port="25" defaultCredentials="true" />
</smtp>

</mailSettings>
</system.net>
</configuration>

Although the .NET Framework contains base implementations for a number of cryptographic algorithms, such as the hashing function, sometimes it is necessary to override these algorithms. When this is required, the cryptographySettings section of the configuration file can be included to remap existing algorithm names, or map new names, to another implementation class.

Debugging is always the hardest part of writing an application. It is made even more difficult when the application is in production and the error cannot be replicated in the debugging environment. One technique that is particularly important for debugging this type of error is to use trace statements:

Trace.WriteLine("The application made it this far before crashing.")

Both trace and debug statements work very similarly to events and event handlers. For the preceding WriteLine statement to have any effect, an object must be listening for this WriteLine. This is typically done by a TraceListener class. The framework supports a number of default trace listeners that can be wired up to the application via the diagnostics section of the configuration file, as shown in the following section in which an EventLog trace listener has been attached to the application:

<configuration>
<system.diagnostics>
<trace autoflush="true" indentsize="0">
<listeners>
<add name="MyEventListener"
type="System.Diagnostics.EventLogTraceListener, system,
version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
initializeData="DeveloperApplicationEventLog"/>
</listeners>
</trace>
</system.diagnostics>
</configuration>

The initializeData attribute specifies a text string to be passed into the constructor for the trace listener. In the case of the event-log listener, this text corresponds to the name of the event log into which trace statements will be inserted.

Other elements can also be added to the diagnostics section of the configuration file — for example, to determine the level of trace logging to perform, which will determine how verbose the trace messages are; or to control whether or not the debug assertion dialog is displayed for an application.

The system.web section of the configuration file is used to control how web applications behave. This is the section that can have quite a deep hierarchy, because configuration settings can be specified on a machine, web server, web site, web application, or even subfolder basis. Because this section controls the security requirements for a web application, it is often used to restrict access to certain areas of the web application.

<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpSoap"/>
<remove name="HttpPost"/>
<remove name="HttpGet"/>
<add name="Documentation"/>
</protocols>
</webServices>
</system.web>
</configuration>

The compiler section of the configuration file is used to list the compilers installed on a computer. The following snippet shows how the VB.NET compiler is referenced in the machine.config file. Within an application, this information can be accessed via the CodeDomProvider framework class.

<configuration>
<system.codedom>
<compilers>
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</compilers>
</system.codedom>
</configuration>

All configuration elements can specify a configSource, which is simply a redirection to a separate file. This can be useful if a configuration file becomes unwieldy in length. The following code snippet illustrates how a section of a configuration file can be extracted and subsequently referenced by means of this attribute:

<!—Original Configuration File—>
<configuration>
.
<WindowsApplication1.My.MySettings>
<setting name="Button1_Text" serializeAs="String">
<value>Press Me!</value>
</setting>
</WindowsApplication1.My.MySettings>
</configuration>

<!—Reduced Configuration File using configSource—>
<configuration>
.
<WindowsApplication1.My.MySettings configSource="MySettings.Config" />
</configuration>

<!—Code from MySettings.Config—>
<WindowsApplication1.My.MySettings>
<setting name="Button1_Text" serializeAs="String">
<value>Press Me!</value>
</setting>
</WindowsApplication1.My.MySettings>

Note a couple of limitations to using a configSource:

Each element within the configuration file inherits a number of attributes that can be set to control whether or not that element can be overridden. To prevent an element, or even an entire section, from being overridden, you can lock it. Five different locking attributes (outlined in Table 36-1) can be used to specify any number of configuration attributes and elements that are to be locked.

Being able to lock configuration items is particularly relevant when you're dealing with web applications, which might contain a deep hierarchy of configuration inheritance. Windows applications inherit only from the machine.config file, so it is unlikely that you will need to lock items.

The first technique is to use the predefined appSettings section of the configuration file. This section can be used to store simple name-value pairs of application settings, which might be useful for storing the name of the server, as in the following example:

<configuration>
<appSettings>
<add key="Server" value="http://www.builttoroam.com"/>
</appSettings>
</configuration>

This value can easily be accessed within code by means of the AppSettings property of the ConfigurationManager class (which requires a reference to the System.Configuration assembly):

One of the weaknesses of this approach is that the name of the setting is specified as a string, rather than as a strongly typed property. It also assumes that the value will be a string, which is often not the case.

Using the Settings tab of the project properties designer, you can define application settings of a variety of types. Figure 36-1 illustrates how the PrimaryServer setting would appear in this designer.

Figure 36-1. Figure 36-1

Adding application settings via this designer does not use the appSettings section as you might expect. Instead, it defines a new section in the configuration, as discussed earlier in the section on the configSection element and shown in the following snippet:

<configuration>
...
<ConfigurationApplication.My.MySettings>
<setting name="PrimaryServer" serializeAs="String">
<value>www.builttoroam.com</value>
</setting>
</ConfigurationApplication.My.MySettings>
</configuration>

To access this setting in code, you can make use of the generated strongly typed access properties.

The third mechanism for storing application-specific information is the use of dynamic properties. These are typically used to dynamically set designer properties. For example, you could set the text on a Button1 using the following configuration block:

<configuration>
...
<applicationSettings>
<ConfigurationApplication.My.MySettings>
<setting name="Button1_Text" serializeAs="String">
<value>Press Me Now!</value>
</setting>
</ConfigurationApplication.My.MySettings>
</applicationSettings>
</configuration>

You will note that the preceding code uses the same syntax as application settings defined using the project properties designer. In fact, they are one and the same, the only difference being that in the InitializeComponent method of the form there is a line of code that sets the button text:

When this application is deployed, the text displayed on Button1 is dynamically loaded from the configuration file. In the following steps, for example, you set the size of a control, Button1, to be dynamically loaded from the configuration file:

Developers often want to include more structured information in the configuration file than can be stored in the appSettings section. To solve this problem and eliminate any need for additional configuration files, you can create a custom configuration section. The new configuration section must be defined at the top of the configuration file via the configSection element, complete with a reference to a class that should be used to process that portion of the configuration file.

In the past this process was fairly complex, because the class needed to implement the IConfigurationSectionHandler interface. This exposed a simple method, Create, which was called the first time that section was referenced in code. There was little support from the framework to process the section, and a class implementing this interface often resorted to parsing the XML block to determine settings.

Visual Studio 2010 provides much better support for creating custom configuration sections via the ConfigurationSection and ConfigurationElement classes. These provide the bases for creating classes that map to the structure of the data being stored in the configuration files. Instead of mapping a class that processes the configuration section, you can now create a much simpler class that maps to the section. When the section is referenced in code, an instance of this class is returned with the appropriate data elements set. All the XML processing that would have been necessary in the past is now handled by the .NET Framework.

Although this mapping makes the process of writing a custom configuration section much easier, you may sometimes want more control over how the section is read. Two options can be used to give you this control:

If you need to use either of these options, it might be worth taking a step back and determining whether the configuration section structure is actually in a format suited to the data being stored.

In the following example your application requires a list of registered entities with which to work. One type of entity is a company, and you need to be provided with both the company name and the date on which it was registered. The XML snippet that you would like to have in the configuration file might look like the following:

<RegisteredEntities>
<Companies>
<add CompanyName="Random Inc" RegisteredDate="31/1/2005" />
<add CompanyName="Developer Experience Inc" RegisteredDate="1/8/2004" />
</Companies>
</RegisteredEntities>

Once generated, the corresponding classes that would map to the preceding snippet might look like the following (again, this requires a reference to the System.Configuration assembly):

The code contains three classes that are required in order to correctly map the functionality of this section. The registered entities section corresponds to the RegisteredEntities class, which contains a single property that returns a company collection. A collection is required here because you want to be able to support the addition of multiple companies. This functionality could be extended to clear and/or remove companies, which might be useful if you had a web application for which you needed to control which companies were available to different portions of the application. Lastly, there is the Company class that maps to the individual company information being added.

To access this section from within the code, you can simply call the appropriate section using the configurationManager framework class: