Configuration Structure
ASP.NET configuration files are called Web.config files, and they can appear in multiple directories within an ASP.NET application. The ASP.NET configuration hierarchy has the following characteristics:
Use a configuration file that applies to resources in the directory in which the configuration file is located and all its subdirectories.
Allows you to place configuration data in a location that will give it the appropriate scope (the entire computer, all Web applications, a single application, or a subdirectory within that application).
Allows overriding configuration settings inherited from higher levels in the configuration hierarchy. Also allows locking configuration settings to prevent them from being overwritten by lower-level configuration settings.
Organize logical groups of configuration settings into sections.
Configuration inheritance
All .NET Framework applications inherit basic configuration settings and defaults from a file named systemrootMicrosoft .NETFrameworkversionNumberCONFIGMachine.config. The Machine.config file is used for server-level configuration settings. Some of these settings cannot be overridden in configuration files located lower in the hierarchy.
.NET client applications (console and Windows applications) use a configuration file named ApplicationName.config to override inherited settings. ASP.NET applications use a configuration file named Web.config to override inherited settings.
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 settings from the Machine.config file. The root Web.config file contains settings that apply to all ASP.NET applications running a specific version of the .NET Framework. Because every ASP.NET application inherits default configuration settings from the root Web.config file, you only need to create Web.config files for settings that override the default settings.
Inheritance in Collection Elements
Some configuration elements are collections, for example, the namespaces element and the customErrors element.
In a collection, configuration settings are usually added to the collection through the add child element, removed by key name through the remove child element, or the entire collection can be cleared through the clear child element. Unless duplicates are allowed, settings added in a child profile will override settings with the same key name in the parent profile.
Note
that some collections that existed in earlier versions of the .NET Framework used different element names for add child elements. For example, the customErrors element uses the error child element to add custom errors to the collection.
If a request is received for a file that does not exist in the SubDir1 directory, ASP.NET will begin searching the configuration hierarchy and start from the most local Web.config file (if it exists, it may be in the current directory or it may be in the current directory). in the parent directory). ASP.NET will search the error element (ASP.NET Settings Schema) element of customErrors for a statusCode attribute equal to "404". Once ASP.NET finds a 404 error in the configuration settings, the URL in the redirect attribute is returned as the response.
Scope of configuration settings
Configuration settings have different scopes - some have global scope and some are only valid for application scope (root Web.config file or Machine.config file).
The scope of a configuration section is defined for all sections contained in ASP.NET in the allowDefinition attribute of the configSections section element (General Settings Schema) element in the Machine.config file. For example, the authentication element (ASP.NET Settings Schema) element has the allowDefinition attribute of the MachineToApplication element. This means that the authentication element can be set in 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 will be thrown. If the allowDefinition attribute is not defined for a section, the default value is Everywhere.
The scope of configuration settings for each element in ASP.NET configuration settings and general configuration settings (ASP.NET) is listed next to Configurable in the Element Information table.
The following table lists each file's level in the configuration hierarchy, the name of each file, and a description of the important inherited characteristics of each file.
| Configuration Level | File Name | File Description |
| Server | Machine.config | The Machine.config file contains the ASP.NET schema for all Web applications on the server. This file is at the top level of the configuration merge hierarchy. |
| The root Web | Web.config | server's Web.config file is stored in the same directory as the Machine.config file and contains default values for most of the system.web configuration section. At run time, this file is merged from the second level from the top in the configuration hierarchy. |
| Site | Web.config | The Web.config file for a specific site contains settings that apply to that site and are inherited down to all ASP.NET applications and subdirectories of that site. |
| ASP.NET Application Root | Web.config | The Web.config file for a specific ASP.NET application is located in the root directory of the application. It contains the set up. |
| ASP.NET Application Subdirectory | Web.config | The Web.config file for an application subdirectory contains settings that apply to this subdirectory and are inherited downward to all subdirectories in its branches. |
| Client Application Directory | ApplicationName.config TheApplicationName.config | file contains settings for Windows client applications (not Web applications). |
ProcessModel Element
The processModel element (ASP.NET Settings Schema) element configures the processing model used for the server (including all ASP.NET applications on the server). Therefore, processModel settings can only be placed in the Machine.config file and cannot be overridden by settings in any Web.config file.
Changes to the processModel element will only take effect after the worker process is restarted, rather than immediately after setting changes like other configuration elements.
Note
When ASP.NET runs in Internet Information Services (IIS) 6.0 in worker process isolation mode, the IIS 6.0 process model is used and the setting in the processModel section of the Machine.config file is ignored. To configure process identity, round-robin, or other process model values, use IIS Manager to configure the application's IIS worker process.
Run-time calculation of configuration settings
When the server receives a request for a specific Web resource, ASP.NET hierarchically calculates the configuration settings for that resource using all configuration files located in the virtual directory path of the requested URL. Local configuration settings override settings in the parent configuration file.
These settings are calculated once and then cached for subsequent requests. ASP.NET automatically monitors changes to a file and recalculates the cache when any configuration file within the file's hierarchy changes. When the server receives a request for a specific URL, ASP.NET uses the hierarchy of configuration settings in the cache to find the requested resource.
Unless the restartOnExternalChanges="false" attribute is included in the configuration section element, or the configuration settings are contained in a separate file linked to the Web.config file using the configSource attribute, the application will restart when the configuration changes.
Multiple ASP.NET resources configured in a single file
Storing settings for multiple locations in a single Web.config file can be useful when managing a large number of configuration settings or managing client websites in an ISP setting. 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.
Settings in virtual directories conflict with settings in physical directories
Configuration settings for virtual directories are independent of the physical directory structure, and virtual directories must be organized carefully to prevent configuration problems. For example, you might have an ASP.NET file named MyResource.aspx with the following physical directory structure.
C:
Subdir1
Subdir2
MyResource.aspx
Additionally, you may have a configuration file located at Subdir1, a virtual directory named Vdir1 mapped to c:Subdir1, and a virtual directory named Vdir1 mapped to c:Subdir1Subdir2 The virtual directory of Vdir2. If a client uses the URL http://localhost/vdir1/subdir2/MyResource.aspx to access a resource physically located at c:Subdir1Subdir2MyResource.aspx, the resource inherits the configuration settings from Vdir1. However, if a client accesses the same resource using the URL http://localhost/vdir2/MyResource.aspx, the resource does not inherit the settings from Vdir1. Creating virtual directories in this manner may cause unexpected results or even cause the application to fail. It is recommended that you do not nest virtual directories, and if you must, use only one Web.config file.
Limiting ASP.NET Inheritance
You may want to limit the inheritance of configuration settings to enhance application performance, maintain high reliability, and simplify administration. Restriction functionality is controlled by the allowOverride, lockAttributes, lockAllAttributesExcept, lockAllElementsExcept, lockItem, and lockElements properties. See msdn for more information on these properties.