ASP.NET 配置文件的层次和继承关系
ASP.NET 通过在应用程序的任意目录保存配置文件的方式实现 ASP.NET 配置文件的层次继承化管理。这种结构允许开发者对应用程序特定目录进行更细节化的配置，并且配置结果不会影响到更高层的目录级别。
本文包含下列内容：
配置结构
ASP.NET 的配置文件被称为 Web.config 文件，该文件可以在 ASP.NET 应用程序的多个目录中同时出现。同时，ASP.NET 的配置层次还具有下列特性：
-
配置文件可以应用于同一目录和子目录中的各种资源。
-
可以根据需要应用不同的配置作用范围（整台计算机，所有 Web 应用程序，单个应用程序，或应用程序中的某个目录），并设置各种类型的配置数据。
-
由配置层次中从更高级别继承来的配置允许被重载，也允许对配置的锁定以防止来自于低级别配置的覆盖。
-
对配置进行组织并按逻辑分组成为不同的配置段。
配置继承
所有 .NET Framework 应用程序都会继承最基本的配置和 系统目录\Microsoft .NET\Framework\版本号\CONFIG\Machine.config 文件的默认配置。而 Machine.config 文件则用于整个服务器的配置。另外，配置文件层次中还有一些不能被覆盖的配置段。
.NET 客户应用程序（控制台应用程序和 Windows 应用程序）使用以 应用程序名.config 格式命名的配置文件来覆盖被继承的默认配置。ASP.NET 应用程序则使用名为 Web.config 的文件对被继承的配置进行覆盖。
ASP.NET 配置层次的根是一个作为根被引用的 Web.config 文件，该文件和 Machine.config 文件位于同一个目录中。根 Web.config 文件继承了 Machine.config 文件中的所有配置。根 Web.config 文件也包括应用于特定版本的 .NET Framework 环境中运行的所有 ASP.NET 应用程序的配置。因为每个 ASP.NET 应用程序都从根 Web.config 文件中继承默认的配置，所以开发者需要创建新的 Web.config 文件以覆盖默认配置。
元素集合的继承
有些配置元素是以集合的方式存在的：如 namespaces 元素和 customErrors 元素。
集合中的配置通常使用 add 子元素才能够添加到集合中，并通过 remove 子元素使用关键字进行删除，或者为整个集合使用 clear 子元素进行全部清空。添加在子配置文件中的配置会覆盖掉父配置文件中的同名配置，除非允许对配置进行复制。
提示：一些存在于较早版本的 .NET Framework 中的集合为 add 元素中使用不同的元素名称。比如，customErrors 元素使用的是 error 子元素为集合添加自定义错误。
如果 SubDir1 目录中被请求的文件并不存在，ASP.NET 就会先从局部 Web.config 文件（定位于当前目录，如果不存在则定位于父目录）的位置开始对配置层次进行搜索。ASP.NET 将会搜索 customErrrors 元素中 statusCode 参数值为 "404" 的 error 元素。一旦找到该 404 号错误的配置，那么就返回设置在 redirect 参数中的值。
配置的作用范围
配置的作用范围也有多种：如全局范围、当前应用程序范围、根 Web.config 文件、或 Machine.config 文件。
ASP.NET 包含的 Machine.config 文件定义所有配置段的作用范围，所有配置段被定义在 configSections section 子元素的 allowDefinition 参数中。比如，authentication 元素中含有 allowDefinition 参数的 MachineToApplication 子元素，表示 authentication 元素可以分别在 Machine.config 文件、根 Web.config 文件、或应用程序级别的 Web.config 文件中进行配置。当该元素设置在子目录级别时会产生一个错误。如果没有定义配置段的 allowDefinition 参数，那么就会使用默认值 Everywhere。
下表列出位于不同配置层次的文件级别、文件名、以及对重要继承特性的描述。
| 配置级别 | 文件名 | 文件描述 |
|---|---|---|
服务器 |
Machine.config |
Machine.config 文件包含服务器所有 Web 应用程序的配置结构。该文件位于配置层次的最顶层。 |
所有 Web 站点 |
Web.config |
服务器的 Web.config 文件与 Machine.config 位于同一目录中，并且包含 |
单个 Web 站点 |
Web.config |
特定 Web 站点的 Web.config 文件，包含了网站子应用程序和子目录的配置。 |
ASP.NET 应用程序根目录 |
Web.config |
特定 ASP.NET 应用程序的 Web.config 文件，位于应用程序根目录，且包含了应用于 Web 应用和所有子目录的配置。 |
ASP.NET 应用程序子目录 |
Web.config |
应用程序子目录的 Web.config 文件，包含了应用于目录本身和下级子目录的配置。 |
客户应用程序目录 |
应用程序名.config |
应用程序名.config 文件包含了 Windows 客户应用程序（非 Web 应用程序）的配置。 |
ProcessModel 元素
processModel 元素用于配置服务器处理模型，包括服务器中的所有 ASP.NET 应用程序。因此，processModel 配置只能够放在 Machine.config 文件中，并且无法被任何 Web.config 文件覆盖。
与其他配置元素不同的是，对 processModel 元素的更改只会在工作者进程重新启动时才会生效。
提示：当 ASP.NET 在 Internet Information Services（IIS）6.0 的工作者进程隔离模式下运行时会使用 IIS 6.0 的默认进程模型，并忽略 Machine.config 文件中的 processModel 配置段。如果要配置进程的唯一性、可回收性、或使用其他的进程模型时，请使用 IIS 管理器为应用程序配置 IIS 工作者进程。
运行时的配置计算
当服务器接收到对特定 Web 资源的请求时，ASP.NET 会计算并合并资源的配置层次，甚至为 URL 请求动用所有虚拟路径下的配置文件。当然，局部配置会对父配置文件的配置进行覆盖。
配置层次在第一次计算之后随即被缓存起来用于其他并发请求的服务。ASP.NET 还自动监视文件并在这些文件被更改之后对其进行重新编译并缓存。在服务器接收到特定的 URL 请求时，ASP.NET 会优先从已缓存的配置层次中找出相应的被请求资源。
应用程序会在配置被更改之后自动重新启动，除非配置段元素中包括 restartOnExternalChanges="false" 参数，亦或配置是保存在由 configSource 参数链接到 Web.config 文件的单独文件中。
在同一个文件中配置多个 ASP.NET 资源
在管理多个配置或用同一个 ISP 配置来管理客户网站时，就可以在同一个 Web.config 文件中保存多种位置的配置。比如，使用 location 元素的 path 参数，开发者就可以为多个保存在应用程序子目录中的特定 ASP.NET 资源进行配置。
虚拟路径与物理路径之间的配置冲突
虚拟目录的配置依赖于物理目录的结构，而且对虚拟目录的组织应该谨慎，以避免出现配置问题。比如，假设开发者有一个位于下例物理目录结构中的 MyResource.aspx 文件。
C:
\Subdir1
\Subdir2
\MyResource.aspx
另外，开发者可能还需要一个 Subdir1 目录下的配置文件，虚拟目录 Vdir1 被映射到 c:\Subdir1，而虚拟目录 Vdir2 则被映射到 c:\Subdir1\Subdir2。如果某个客户端使用 http://localhost/vdir1/subdir2/MyResource.aspx 对物理位置的 c:\Subdir1\Subdir2\MyResource.aspx 文件进行访问，该资源就会对虚拟目录 Vdir1 的配置进行继承。但是，如果客户端使用 http://localhost/vdir2/MyResource.aspx 访问相同的资源时，情况就不同了，实际是资源并不从 Vdir1 那里继承配置。使用相同方式创建虚拟目录时还会导致无法意料的结果，甚至可能引起应用程序产生错误。所以建议还是不要使用嵌套的虚拟路径，如果一定要用，那就请只使用一个 Web.config 文件。
限制 ASP.NET 的配置继承
开发者可能需要对配置的继承进行限制以提高应用程序性能、提高可靠性、以及简化管理。这个需求可以通过使用 allowOverride、lockAttributes、lockAllAttributesExcept、lockAllElementsExcept、lockItem 和 lockElements 参数来实现。