asp.net 配置文件层次结构和继承_asp.net技巧

　　您可以在整个应用程序目录中分发 ASP.NET 配置文件，以便以继承层次结构配置 ASP.NET 应用程序。使用此结构，可以在适当的目录级别实现应用程序所需级别的配置详细信息，而不影响较高目录级别中的配置设置。

　　配置结构

　　ASP.NET 配置文件称为 Web.config 文件，它们可以出现在 ASP.NET 应用程序的多个目录中。ASP.NET 配置层次结构具有下列特征:

　　使用应用于配置文件所在的目录及其所有子目录中的资源的配置文件。

　　允许您将配置数据放在将使它具有适当范围(整台计算机、所有的 Web 应用程序、单个应用程序或该应用程序中的子目录)的位置。

　　允许重写从配置层次结构中的较高级别继承的配置设置。还允许锁定配置设置，以防止它们被较低级别的配置设置所重写。

　　将配置设置的逻辑组组织成节的形式。

　　配置继承

　　所有的 .NET Framework 应用程序都从一个名为 systemroot\Microsoft .NET\Framework\versionNumber\CONFIG\Machine.config 的文件继承基本配置设置和默认值。Machine.config 文件用于服务器级的配置设置。其中的某些设置不能在位于层次结构中较低级别的配置文件中被重写。

　　.NET 客户端应用程序(控制台和 Windows 应用程序)使用名为 ApplicationName.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 将搜索 statusCode 属性等于“404”的 customErrors 的 error 元素(ASP.NET 设置架构)元素。一旦 ASP.NET 在配置设置中找到 404 错误，将 redirect 属性中的 URL 作为响应返回。

　　配置设置的范围

　　配置设置具有不同的范围 – 有些具有全局范围，有些仅对应用程序范围(根 Web.config 文件或 Machine.config 文件)有效。

　　配置节的范围是在 Machine.config 文件中的 configSections 的 section 元素(常规设置架构)元素的 allowDefinition 属性中为包含在 ASP.NET 中的所有节定义的。例如，authentication 元素(ASP.NET 设置架构)元素具有 MachineToApplication 元素的 allowDefinition 属性。这意味着，authentication 元素可以在应用程序级别的 Machine.config 文件、根 Web.config 文件和 Web.config 文件中设置。如果它是在子目录级别设置的，则会引发错误。如果没有为某个节定义 allowDefinition 属性，则默认值为 Everywhere。

　　“元素信息”表中“可配置的位置”旁边列出了 ASP.NET 配置设置 和 常规配置设置 (ASP.NET) 中每个元素的配置设置范围。

　　下表列出了每个文件在配置层次结构中的级别、每个文件的名称以及对每个文件的重要继承特征的说明。

　　ProcessModel 元素

　　processModel 元素(ASP.NET 设置架构)元素配置用于服务器(包括服务器上的所有 ASP.NET 应用程序)的处理模型。因此，processModel 设置只能放在 Machine.config 文件中，而且不能被任何 Web.config 文件中的设置重写。

　　对 processModel 元素的更改将只有在辅助进程重新启动之后才生效，而不是像其他配置元素那样在设置更改之后立即生效。

　　注意

　　当 ASP.NET 以辅助进程隔离模式运行在 Internet 信息服务 (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 资源进行配置。

　　有关如何使用 location 元素的信息，请参见如何:使用位置设置配置特定目录。

　　虚拟目录中的设置和物理目录中的设置发生冲突

　　虚拟目录的配置设置独立于物理目录结构，必须小心组织虚拟目录以防止出现配置问题。例如，您可能有一个具有如下物理目录结构且名为 MyResource.aspx 的 ASP.NET 文件。

　　C:

　　\Subdir1

　　\Subdir2

　　\MyResource.aspx

　　另外，您还可能拥有一个位于 Subdir1 的配置文件、一个映射到 c:\Subdir1 的名为 Vdir1 的虚拟目录以及一个映射到 c:\Subdir1\Subdir2 的名为 Vdir2 的虚拟目录。如果客户端使用 URL http://localhost/vdir1/subdir2/MyResource.aspx 访问物理位置为 c:\Subdir1\Subdir2\MyResource.aspx 的资源，则该资源将从 Vdir1 继承配置设置。但是，如果客户端使用 URL http://localhost/vdir2/MyResource.aspx 访问同样的资源，则该资源不从 Vdir1 继承设置。以这种方式创建虚拟目录可能会导致意外的结果，甚至会导致应用程序失败。建议您不要嵌套虚拟目录，如果不得不这样做的话，请只使用一个 Web.config 文件。

　　限制 ASP.NET 继承

　　您可能希望限制配置设置的继承，以增强应用程序的性能、保持高可靠性并简化管理。限制功能由 allowOverride、lockAttributes、lockAllAttributesExcept、lockAllElementsExcept、lockItem 和 lockElements 属性控制。有关这些属性的更多信息，请参见msdn。