作者：Tobin Titus

IIS 7 及更高版本中的配置系统与以前版本的 IIS 大有不同，并且其中一些（但并非全部）是基于 .NET Framework 配置系统的概念。 其范围跨越整个 Web 服务器平台（IIS，ASP.NET），并充当 IIS 管理“堆栈”的核心。 本文档介绍了配置系统的设计和体系结构，并在最低级别（本机代码）的入口点介绍了系统的可编程接口。

在运行时很少有实现配置系统的“移动部件”。 配置系统作为一个库实现，该库在客户端应用程序中运行，并与磁盘上的持久存储进行交互。 存储简单说就是文件系统上的一个文件或一组文件。 文件的格式为 XML。 用户可以随时手动编辑文件（如果需要）并且系统会自动获取更改。 没有专门的模型来执行标准操作，如保护设置、备份设置、移动设置，甚至使用新设置扩展系统。 系统严重依赖文件系统，从而简化部署 Web 应用程序和服务的配置等任务。

注意

与以前版本的 IIS 中一样，没有集中式配置服务。 从存储中读取大块数据时，尤其是在启动时，这可以显著提高性能，因为不需要进行进程间通信和缓冲区复制。

安装 IIS 后，有几项配置立即需要设置：

有几个接口提供对配置设置的访问权限：

URL 命名空间的每个级别都有关联的配置。 给定级别的配置将继承到子级别，除非被子级专门替换。 实现按 URL 配置的一种简单方法是在映射到虚拟路径的物理文件系统文件夹中使用 web.config 文件。 在根级别（计算机级别），应使用单独的文件，具体取决于配置节组（稍后将在文档中定义；目前可将其视为包含配置的 XML 元素的名称）：

有时不需要 web.config 文件，或者无法使用。 示例：

配置层次结构中的 web.config 文件的替代方法是位置标记，这将在下一章节中介绍。

位置标记用于指定特定于路径的配置，这样就无需将文件夹中的 Web.config 文件映射到该虚拟路径。 路径的位置标记在配置层次结构中的父级别中设置，并被视为位于该父级别。 当涉及到锁定语义以及哪个级别可以指定哪些节时，这一点很重要。

位置标记中的主要属性是“path”。 值可以是：

单个配置文件中可以有多个位置标记，但这些位置标记不能引用相同的路径（除非引用不同的节）。 但可以引用子路径，以便每个位置标记引用另一个位置标记的子路径。 位置标记的顺序对配置系统来说无关紧要，但对用户文件可读性至关重要。

在配置文件中，根据名为“节”的单元，以结构化方式组织设置。 配置节是一组逻辑相关的设置，可以整体部署或整体从系统注销，并且通常由一个服务器模块使用。

换句话说，在工作进程中运行的几乎每个运行时模块都有相应的配置节。 配置节也是扩展性的单元：将新设置添加到配置架构是向其添加一个或多个节来完成的。

节无法嵌套。 在体系结构上，节是彼此独立的（在大多数情况下），这意味着它们不会彼此交叉引用。

这些节进一步分组到逻辑相关的集合中，称为“节组”。 节组不是部署单元、注册或其他任何实质性操作（例如锁定、加密）。 它们中没有设置。 其用途是进一步构建设置的组织，并避免配置节的长列表。

它们用于生成设置的层次结构，因此它们之间确实有关系（父/子级）。 换句话说，可以嵌套节组。 给定节始终属于一个节组，不能包含其他节（或节组）。 给定节组可能属于父节组，并且可能包含零个或多个子节组。 它通常包含多个节，否则它就没有存在的必要（但是，客户无论出于何种原因，都可以通过创建只有一个节的自己的节组来扩展架构）。

下面是演示节和节组的示例：

每个节都有一个名称。 短名称是节本身的名称，长名称是全名，包括包含的所有节组。 例如，“windowsAuthentication”的全名是“system.webServer/security/authentication/windowsAuthentication”。 此分层组织允许将来创建具有相同名称的节（和节组），但在不同的节组下。

配置的持久性格式为 XML；因此，描述配置组织单位与 XML 术语之间的映射非常有用。 节组和节是 XML 元素。 在一个节中，这些设置被组织为与 XML 术语密切相关的较小单元：

下面是 applicationHost.config 的示例：

配置系统的核心是一个声明性架构。 这与 IIS 6.0 不同，例如，在 IIS 6.0 中，实际架构是硬编码的，并非由 ABO 使用，并且 ADSI 提供程序（它是 ABO 之上的高级接口）具有自己的架构，客户可以扩展该架构。 这与 .NET Framework v2.0 配置系统的体系结构大相径庭，其中设置的“架构”主要编码为各个类，这些类实现了用于处理各自节的逻辑（这些类称为“节处理程序”）。 声明性架构还意味着只需要向系统添加声明便可以扩展系统，而无需添加代码（与 .NET Framework 方法的另一个区别）。

配置架构跨越多个文件，这些文件都位于以下已知位置：system32\inetsrv\config\schema。 默认情况下，只有计算机管理员有权访问此文件夹。 客户或第三方可以通过将其复制到该目录中来为其自定义节添加架构文件。 在调用方进行配置的过程中，配置系统会在启动时自动选取它们。 如果配置系统已在运行，则不会选取对架构文件或新文件的更改。

请勿编辑安装到此目录中的 IIS 或其他架构文件，因为错误可能会导致架构损坏，以及服务器无法启动。

注意

没有用于获取和设置架构文件的高级程序设计界面，无需传统文件访问 API 和 XML 分析/编辑。 在对架构文件夹进行任何更改之前，始终建议备份敏感状态（如架构文件夹）。

三个文件构成了 Web 服务器平台的统一架构：

在架构文件中，组织是基于节的单位。 节由其全名定义，包括包含节组。 节组本身没有定义；它们用作节名称的一部分，以指示层次结构。 每个节架构声明都指定节设置的名称、类型和默认值。 还指定节中的结构：子元素、集合、属性。

我们将在这里回顾一个例子，用 XML 注释来指出一些要点。强烈建议您阅读“ApplicationHost 演练，以更详细了解架构系统的工作方式，并查看每个 IIS 节的架构。

示例：

架构 XML 文件中不一定包含了所有必需的信息。 其中一些内容位于名为 “特殊”部分，它驻留在配置文件本身中。 这与 .NET Framework 配置系统一致。 默认情况下，machine.config 和 applicationHost.config 中存在 ；但客户可能会将其添加到任何 web.config 文件中，以定义其自定义节。 将为命名空间中的该级别和更低级别定义这些节。

注意

客户和第三方不应尝试在 inetsrv\config\schema\ 文件夹或是在 machine.config 和 applicationHost.config 中更改内置节的架构信息。这可能会导致这些节出现意外行为。

以下内容的内容 ：

还为节定义了一些其他元数据：

下面是 applicationHost.config 中的简化代码片段：

位置标记通常用于锁定或解锁整个节。 配置系统也支持更精细的锁定，即锁定节内的元素和属性，但这与位置标记没有直接关系。

只能在定义锁定的级别完成解锁。 换句话说，某个配置级别永远无法解锁父级别锁定的内容。 例如，节默认未锁定，因此 applicationHost.config 中的这些位置标记将锁定两个特定站点：

在上面的示例中，第一个位置标记只是锁定 MySite 的节，其中包含已为其定义的任何值。 第二个位置标记会更改值（通过启用节、清除文件集合并向其添加一个元素），并且还会针对 YourSite 将其锁定。 这意味着在 YourSite 级别 (web.config)，默认文档功能始终处于打开状态，并且无法关闭，唯一默认的文档是 default.aspx。

上面的示例只是稍作更改，就可以在低级 web.config 文件中进行设置，而不仅仅是在 applicationHost.config 中。配置层次结构的任何级别都可以锁定配置（对于其下层的路径，这就是为什么在示例中需要稍作更改以反映路径的不同值）。

具有相同节的位置标记可以跨越层次结构的多个级别，就像 web.config 文件一样。 将根据继承规则来评估这些位置标记。 我们不会在这里确切地指定如何相对于层次结构中位置标记下面的 web.config 文件来评估位置标记，因为该算法可能会使试图创建清晰的继承层次结构（有时是锁定配置）的人类用户感到困惑。 由于这些原因，位置标记有时可能会令人困惑，或者比简单地使用 Web.config 文件更高深。 但是，如前面在“体系结构”一节中所述，在某些情况下，有充分的理由使用位置标记。

上面的示例中的锁定是使用 overrideMode 属性完成的。 有效值为：

系统还支持在位置标记中锁定分区的旧属性：allowOverride。 .NET Framework 配置系统中曾经使用过此属性（在 overrideMode 出现之前）。 它以如下方式映射到 overrideMode 语义：

allowOverride 模型存在一些限制，而且自身也很复杂，我们在这里不予以介绍。 因此，建议使用新模型 overrideMode。

位置标记不能同时指定 allowOverride 和 overrideMode。 这会被视为非法配置，在运行时会失败并显示相应错误。

此示例演示如何解锁节。 由于节是在 applicationHost.config 级别锁定的，因此只能在该级别解锁。

以下操作在特定情况下很有用：仅对特定路径的节进行解锁，而对所有其他路径保持锁定。 下面的示例在前一个示例的基础上构建，并显示如何仅为两个特定站点解锁该节。对于所有其他站点，该节仍将保持锁定状态。

对于需要解锁的每个特殊路径，需要有一个不同的位置标记。

当锁定和解锁之间发生冲突时，可能会出现复杂情况。 请看以下示例：

此冲突发生在 applicationHost.config 级别与 MySite 根目录的 web.config 之间，前者专门为 MySite/shopping 解锁节，后者又锁定了此站点的节。 当不同人员管理这些不同级别的层次结构的配置时，可能会发生这种情况。 在这种情况下，配置系统会将其视为非法配置，配置系统失败并显示相应错误。

本文档概述了 IIS 配置系统的设计和体系结构。 解释了如何使用配置级别层次结构和分布式 web.config 文件来实现配置设置的委托管理。涵盖了 IIS 和 .NET Framework 配置系统之间的集成点（包括限制）。解释了标记的概念，以及在什么情况下标记应该优先于配置文件。还向读者介绍了节级别的基本配置锁定。 建议阅读“如何锁定配置”文档，以更深入地了解配置锁定，包括节中的精细锁定。

本文档还介绍了配置文件中的设置的组织方式，并介绍了节、节组、元素、属性、集合、枚举和标志的概念。

最后，文档介绍了架构系统及其工作原理；这对于使用自定义设置扩展系统时非常有用。 建议阅读“如何扩展配置”文档，以了解详情以及有关将自定义配置节添加到系统以及生成代码以使用自定义配置节的具体说明。