• Choose a category
• All
• Classic-Fiction

The ASP.NET runtime processes configuration information hierarchically, proceeding from a root common to all applications on the machine—machine.config—down to all the web.config files found in the various folders of the particular application.

Note

The machine.config file is located in the CONFIG directory under the ASP.NET installation folder. The installation folder is located under the Windows directory at the following path: \Microsoft.NET\Framework\[version]\. For the .NET Framework 4, the version folder is v4.0.30319. If you take a look at the contents of the CONFIG directory, you’ll find three similar files: machine.config, machine.config.default, and machine.config.comments. Provided for educational purposes, the latter two files provide the description and default values of each configuration section. To gain a bit of performance, and a lot of readability, the contents of the machine.config file contain only the settings that differ from their defaults.

The Tree of Configuration Files

When an ASP.NET application starts, all configurable parameters are set to the default values defined in machine.config. These values can be overridden in the first place by a web.config file placed in the root folder of the application. The web.config file can also add new application-specific settings. In theory, a root web.config file can also clear all the settings in the original machine configuration and replace them altogether. However, in practice it is rare that you would reconfigure ASP.NET for your application to this extreme.

You can also define additional web.config files in child folders to apply other settings to all the resources contained in the subtree rooted in the folder. Also in this case, the innermost web.config can overwrite, restrict, or extend the settings defined at upper levels. Figure 3-1 illustrates how ASP.NET processes system and application settings for each page in the Web site.

Figure 3-1. The hierarchical nature of ASP.NET configuration.

Configuring the machine file is an administrative task and should be performed with the server offline when the application is deployed or during periodical maintenance. Application settings can be changed on the fly administratively or even programmatically. Usually, changes to the application’s configuration file result in a process recycling. However, in IIS 7 application pools can be configured to make recycling after a configuration change optional.

Important

Only in very special cases should the application write to its web.config file. If you need to persist some data on the server (for example, user profile data), you should take advantage of cookies or, better yet, the user profile API or some custom form of storage. The need for writing to a configuration file should be taken as an alarm bell that warns you against possible bad design choices. ASP.NET comes with a set of tailor-made classes, maps all the feasible sections and nodes in the configuration schema, and exposes methods to read and write. The primary role of configuration files is just the overall configuration of the system, namely a set of options that can be changed offline without recompiling the system.

The Configuration Schema

All configuration files have their root in the element. Table 3-1 lists the main first-level children of the element. Each node has a specified number of child elements that provide a full description of the setting. For example, the element optionally contains the tag, in which you can store information about the users who can safely access the ASP.NET application.

Table 3-1. Main Children of the Element

Element

Description

Contains custom application settings.

Describes the configuration sections for custom settings. If this element is present, it must be the first child of the node.

Lists predefined connection strings that are useful to the application.