asp.net configuration file hierarchy and inheritance

Asp.net| inheritance You can distribute ASP.net configuration files throughout the application directory to configure ASP.net applications in an inheritance hierarchy. With this structure, you can implement configuration details at the appropriate directory level for the level of application required, without affecting configuration settings in higher directory levels.

　　Configuration structure

asp.net configuration files, called Web.config files, can appear in multiple directories in a asp.net application. The ASP.net configuration hierarchy has the following characteristics:

Use a configuration file that applies to resources in the directory where the configuration file resides and all of its subdirectories.

Allows you to place the configuration data where it will have the appropriate scope (the entire computer, all WEB applications, a single application, or a subdirectory in the application).

Allows you to override configuration settings inherited from higher levels in the configuration hierarchy. Also allows you to lock configuration settings to prevent them from being overridden by lower-level configuration settings.

Organize the logical groups of configuration settings into sections.

　　Configure inheritance

All. NET Framework applications are from one named Systemroot\microsoft. Net\framework\versionnumber\config\machine.config File inherits the basic configuration settings and the default values. The Machine.config file is used for server-level configuration settings. Some of these settings cannot be overridden in a configuration file that is located at a lower level in the hierarchy.

. NET client applications (consoles and Windows applications) override inherited settings by using a configuration file named Applicationname.config. The ASP.net application overrides the inherited settings using a configuration file named Web.config.

The root of the ASP.net configuration hierarchy is a file called the root Web.config file, which is located in the same directory as the Machine.config file. The root Web.config file inherits all the settings in the Machine.config file. The root Web.config file includes settings that apply to all ASP.net applications running a specific version of the. NET Framework. Because each asp.net application inherits the default configuration settings from the root Web.config file, you only need to create the Web.config file for the settings that override the default settings.

　　Inheritance in a collection element

Some configuration elements are collections, such as namespaces elements and customErrors elements.

In a collection, you typically add configuration settings to the collection through the Add child element, remove the configuration settings by using the Remove child element key name, or you can clear the entire collection through the purge child element. Unless duplicates are allowed, the settings that are added in the child configuration file override the same key name settings in the parent configuration file.

　　Attention

Some collections that exist in earlier versions of the. NET Framework use different element names for the add child element. For example, the CustomErrors element uses the error child element to add a custom error to the collection.

If you receive a request for a file that does not exist in the SubDir1 directory, ASP.net begins the search configuration hierarchy and starts with the most local Web.config file (if it exists, it may be in the current directory, or it may be in the parent directory of the current directory). ASP.net will search for the customErrors error element (asp.net set Schema) element of the StatusCode property equal to "404". Once asp.net finds 404 errors in the configuration settings, returns the URL in the redirect property as a response.

　　Scope of configuration settings

Configuration settings have different scopes-some have global scope, and some are only valid for application scopes (root Web.config files or machine.config files).

The scope of the configuration section is defined for all sections contained in the ASP.net in the Allowdefinition property of the section element (General Settings Schema) element of the configsections in the Machine.config file. For example, the authentication element (asp.net setting Schema) element has the allowdefinition attribute of the machinetoapplication element. This means that the authentication element can be set at the application-level Machine.config file, the root Web.config file, and the Web.config file. If it is set at the subdirectory level, an error is raised. If no allowdefinition attribute is defined for a section, the default value is everywhere.

The configuration settings for each element in the ASP.net configuration settings and general configuration settings (asp.net) are listed next to the configurable locations in the element information table.

The following table lists the levels of each file in the configuration hierarchy, the name of each file, and a description of the important inheritance characteristics for each file.

Configuration level	Filename	File description
Server	Machine.config	The Machine.config file contains the ASP.net schema for all WEB applications on the server. This file is located at the top level of the configuration merge hierarchy.
Root Web	Web.config	The server's Web.config file is stored in the same directory as the Machine.config file, which contains the default values for most system.web configuration sections. At run time, this file is merged from the top down of the configuration hierarchy from the second tier.
Website	Web.config	The Web.config file for a particular Web site contains settings that apply to the Web site, and inherits down to all ASP.net applications and subdirectories of that site.
Asp. NET application root directory	Web.config	The Web.config file for a particular ASP.net application is located in the root directory of the application and contains settings that apply to the Web application and inherit down to all subdirectories in its branch.
asp.net application subdirectory	Web.config	The Web.config file for the application subdirectory contains settings that apply to this subdirectory and inherit down to all subdirectories in its branch.
Client application Directory	ApplicationName.configApplicationName.config	Files contain settings for Windows client applications, not WEB applications.

　　ProcessModel element

The ProcessModel element (asp.net setup schema) element is configured for the processing model of the server, including all ASP.net applications on the server. Therefore, the ProcessModel setting can only be placed in a Machine.config file and cannot be overridden by any settings in any Web.config file.

Changes to the ProcessModel element will take effect only after the worker process restarts, not as soon as other configuration elements have been set.

　　Attention

When ASP.net is running in worker process isolation mode in Internet Information Services (IIS) 6.0, the IIS 6.0 process model is used and the settings in the ProcessModel section of the Machine.config file are ignored. To configure the process identity, looping, or other process model values, use IIS Manager to configure the IIS worker process for the application.

　　Run-Time Calculation configuration settings

When the server receives a request for a specific WEB resource, ASP.net calculates the configuration settings for that resource hierarchically by using all the profiles in the virtual directory path at the requested URL. The local configuration settings override the settings in the parent configuration file.

These settings are computed once and then cached for subsequent requests. asp.net automatically monitors changes to a file and recalculates the cache when any configuration file in the hierarchy of that file changes. When the server receives a request for a specific URL, ASP.net uses the configuration settings hierarchy in the cache to locate the requested resource.

Unless the restartonexternalchanges= "false" attribute is included in the configuration section element, or if the configuration settings are contained in a separate file that is linked to the Web.config file using the ConfigSource property, or when the configuration changes, The application will reboot.

　　Multiple asp.net resources configured in a single file

When you manage a large number of configuration settings or manage client sites in your ISP settings, it can be useful to store settings for multiple locations in a Web.config file. Using the path attribute of the location element, you can configure multiple specific asp.net resources stored in the application subdirectory.

For information about how to use the location element, see how to: Configure a specific directory using location settings.

　　The settings in the virtual directory conflict with the settings in the physical directory

Configuration settings for virtual directories are independent of the physical directory structure, and you must organize your virtual directories carefully to prevent configuration problems. For example, you might have a asp.net file with the following physical directory structure named Myresource.aspx.

C:

\subdir1

\subdir2

\myresource.aspx

Alternatively, you may have a configuration file located in Subdir1, a virtual directory named Vdir1 that maps to C:\Subdir1, and a virtual directory named Vdir2 that maps to C:\SUBDIR1\SUBDIR2. If a client uses a URL http://localhost/vdir1/subdir2/MyResource.aspx to access a resource with a physical location of c:\Subdir1\Subdir2\MyResource.aspx, the resource is Vdir1 inherit configuration settings. However, if the client accesses the same resource using the URL http://localhost/vdir2/MyResource.aspx, the resource does not inherit from the Vdir1 setting. Creating a virtual directory in this way can result in unexpected results, or even an application failure. It is recommended that you do not nest virtual directories, and if you have to, use only one web.config file.

　　restricting ASP.net inheritance

You may want to limit the inheritance of configuration settings to enhance application performance, maintain high reliability, and simplify management. Restrictions are controlled by the allowoverride, Lockattributes, Lockallattributesexcept, Lockallelementsexcept, Lockitem, and LockElements properties. For more information about these properties, see MSDN.