IIS 7.0 配置与管理全解析
1. 命令执行注意事项
在执行相关命令时,有以下几点需要注意:
- 用你的服务器名称替换
{NAS1.DomainA.local}
(包括花括号),只需输入服务器的 UNC 路径,无需完整路径。
- 严格按照命令原样输入,若此处使用域名,而在 IIS 路径中使用 IP 地址,命令将无法正常工作。
- 针对你所支持的所有框架版本运行该命令。
- 对所有受信任且将被此服务器使用的服务器运行该命令,若有备份或备用服务器,也务必添加。
- 不要重复运行命令,否则由于重复条目,ASP.NET 会运行失败,因为
CasPol.exe
无法检查是否已存在该条目,该命令会更新框架文件夹下
config
子文件夹中的
security.config
文件。
若要从命令提示符获取详细帮助,可在框架文件夹中输入
CasPol.exe /?
。
2. IIS 整体优势与相关解决方案
IIS 是一个强大的 Web 托管平台,能随业务发展而扩展。无论为实现故障转移将服务器扩展到两台,还是因网站成功而扩展到数十台,都需确保 IIS 配置、内容及网站的其他方面保持同步。
新的 IIS 共享配置,结合你对配置文件的优化工作,是一种强大且易于配置的解决方案,可使 Web 服务器的 IIS 设置保持同步。它允许导出包括 RSA 密钥在内的配置,以便在 Web 场中的所有其他服务器上使用。
分布式文件系统(DFS)是保持 Web 场中数据同步的可靠解决方案。你可以仅使用复制功能并在每个 Web 服务器上使用本地内容,也可使用 DFS 命名空间创建所有服务器都指向的完全冗余 UNC 路径。DFS 可用于内容复制和 IIS 配置文件的复制。
当服务器设置为协同工作后,需要一种方法来平衡所有服务器的负载,并在出现故障时做出相应响应。Microsoft 的网络负载均衡器(NLB)随操作系统提供,无需额外下载,且适用于多种环境。若需要更强大的功能,也有许多第三方解决方案可供选择。
3. IIS 7.0 编程配置与管理的进步
IIS 7.0 在管理和编程配置方面有了显著提升。与以往版本相比,它在管理方面取得了长足进步,为广泛的定制奠定了基础。其配置基础架构远超 IIS 6.0,能够扩展架构,使所有编程方法可立即使用自定义扩展,架构不再硬编码到 IIS 中,而是完全可扩展。
同时,从元数据库转向 XML 配置结构,模仿 ASP.NET 结构,IIS 7.0 全面支持许多 .NET 开发人员熟悉的配置方法。而且,IIS 开发团队确保了 IIS 7.0 与现有脚本向后兼容,让你可以继续使用现有代码。
4. 配置文件层次结构
IIS 7.0 的配置文件层次结构包含多个文件,各有其特定的作用和路径,如下表所示:
| 文件 | 路径 | 描述 |
| — | — | — |
|
machine.config
|
%windir%\Microsoft.NET\Framework\<version>\config\
| 包含大部分 .NET 框架部分和设置,体现了 IIS 与 .NET 框架的一体化。 |
|
web.config (root)
|
%windir%\Microsoft.NET\Framework\<version>\config\
| 包含更多特定于 ASP.NET 的部分和设置。 |
|
applicationHost.config
|
%windir%\System32\inetsrv\config (默认)
| 包含 IIS 全局 Web 服务器、配置部分和使用位置标签的站点设置。 |
|
administration.config
|
%windir%\System32\inetsrv\config (默认)
| 包含 IIS 管理器和 IIS 管理器用户的配置。 |
|
redirection.config
|
%windir%\System32\inetsrv\config
| 用于共享配置,允许重新定位
applicationHost.config
和
administration.config
。 |
|
web.config (site)
| 网站根路径 | 包含网站的 ASP.NET 或 IIS 设置,若使用位置标签,可管理子文件夹或文件的设置。 |
|
web.config (application)
| 网站应用程序路径 | 与站点
web.config
文件类似,但可针对单个应用程序。 |
|
Web.config (folder)
| 网站文件夹路径 | 虽然通常不放在常规文件夹中,但
web.config
中的某些部分可在文件夹级别运行。 |
在配置文件加载过程中,可能会出现同一设置存在于多个位置的情况,此时最后加载的设置将生效。例如,对于
directoryBrowse
元素,在
applicationHost.config
的常规部分设置为
false
,其位置标签中设置为
true
,而站点的
web.config
中又设置为
false
,最终结果为
false
。
graph LR
A[machine.config] --> D[全局配置加载]
B[web.config (root)] --> D
C[applicationHost.config] --> D
D --> E[站点 web.config 处理]
5. 集合项处理
在 IIS 和 ASP.NET 配置中,集合项的处理与简单属性不同。不能多次添加相同的集合项,否则会报错。例如,
defaultDocument
元素中的
files
部分可能包含多个集合项:
<defaultDocument enabled="true">
<files>
<add value="default.aspx" />
<add value="default.htm" />
<add value="default.asp" />
<add value="index.htm" />
<add value="index.html" />
</files>
</defaultDocument>
若要更改已存在的集合项,如修改
applicationHost.config
中默认的
X-Powered-By
集合项的值并添加
X-Managed-By
集合项,错误的做法是直接添加:
<httpProtocol>
<customHeaders>
<add name="X-Powered-By" value="ASP.NET v3.5" />
<add name="X-Managed-By" value="The Best Admin" />
</customHeaders>
</httpProtocol>
正确的做法有两种:
<!-- 方法一 -->
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
<add name="X-Powered-By" value="ASP.NET v3.5" />
<add name="X-Managed-By" value="The Best Admin" />
</customHeaders>
</httpProtocol>
<!-- 方法二 -->
<httpProtocol>
<customHeaders>
<clear />
<add name="X-Powered-By" value="ASP.NET v3.5" />
<add name="X-Managed-By" value="The Best Admin" />
</customHeaders>
</httpProtocol>
在
Remove
标签中,无需设置
value
属性,因为只需足够的信息来唯一标识要移除的项即可。
6. 配置文件结构
IIS 和 .NET 配置文件由部分组、部分、元素、属性和集合组成。下面介绍几个核心配置文件:
-
applicationHost.config
:位于
%windir%\System32\inetsrv\config
(默认),包含与激活服务相关的设置,如应用程序池、站点、日志记录设置等。其结构包含
system.applicationHost
、
system.webServer
等部分。
-
administration.config
:同样位于
%windir%\System32\inetsrv\config
,用于 IIS 管理器用户界面和相关设置,如 IIS 管理器用户。
-
redirection.config
:位于
%windir%\System32\inetsrv\config
,用于配置
applicationHost.config
和
administration.config
的位置,以实现共享配置机制,结构简单。
-
machine.config
:特定于 .NET,位于
%windir%\Microsoft.NET\Framework\<version>\config\
,包含大部分 .NET 框架部分和设置,每个框架版本都有对应的文件。
-
web.config (Root)
:与
machine.config
类似,但包含特定于 ASP.NET 的部分和设置,也位于
%windir%\Microsoft.NET\Framework\<version>\config\
。
7. 位置标签的使用
位置标签是配置 ASP.NET 和 IIS 的重要部分。在任何配置文件中,顶级
<configuration>
标签内的设置应用于配置文件所在的目录及其所有子路径。对于全局配置文件,
applicationHost.config
等文件中的设置是所有站点的默认设置。
位置标签可让你为特定子路径指定唯一设置,而无需在该级别实际存在
web.config
文件。例如:
<location path="Default Web Site">
<system.webServer>
<defaultDocument enabled="true">
<files>
<clear />
<add value="default.aspx" />
</files>
</defaultDocument>
</system.webServer>
</location>
此例中,路径设置为
Default Web Site
,意味着该标签内的所有设置将应用于位于
c:\inetpub\wwwroot
的站点,尽管配置是在
%windir%\System32\inetsrv\config
中设置的。
位置标签的
path
属性可能的值及含义如下表所示:
| 值 | 全局配置示例 | 站点或应用程序示例 | 描述 |
| — | — | — | — |
|
.
(或
""
) |
path="."
|
path="."
| 当前级别。在全局配置文件中,指默认设置;在站点或应用程序的
web.config
文件中,指
web.config
文件所在的位置。 |
|
sitename
|
path="Default Web Site"
| N/A | 指定一个站点,可从任何全局配置文件中使用,不能在站点的
web.config
文件中设置为站点名称。 |
|
application
|
path="Site1/App1"
|
path="App1"
| 在站点或应用程序级别,应用程序名称必须是相对路径。 |
|
vdir
|
path="Site1/Vdir1"
|
path="Vdir1"
| 全局级别需包含站点名称,站点级别不能包含。 |
|
physicaldir
|
path="Site1/PhysicalDir1"
|
path="Physical Dir1"
| 简单文件夹无需是应用程序或虚拟目录,即可应用 IIS 或 ASP.NET 设置,但多数设置被锁定,只能在应用程序根目录外设置。 |
|
file.ext
|
path="Site1/default.aspx"
|
path="login.aspx"
| 可用于配置文件,使用位置标签是配置文件设置的唯一方法。 |
多个位置标签可存在于同一配置文件中,只要不引用相同部分或具有不同的
overrideMode
。创建位置标签时,必须包含到该部分的完整路径,且不能嵌套位置标签。
位置标签可用于多种目的:
- 控制与配置文件位置不同的站点或应用程序的设置。
- 将所有设置集中到单个文件,便于管理。
- 将设置应用于文件而非文件夹。
- 锁定某些部分。
- 禁用继承。
- 在全局配置文件中应用默认设置,同时保留默认安装设置不变。
8. 继承问题及解决方法
默认情况下,所有设置会在相关的子站点、应用程序、文件夹和文件中继承。但在处理 ASP.NET 应用程序时,应用程序文件夹和文件不会跨应用程序边界继承。例如,若根站点的
\bin
文件夹中有一个模块,并在
web.config
的
<module>
部分引用,但子文件夹
App1
被标记为应用程序,由于
web.config
继承,
App1
应用程序中仍会有该模块的引用,但只要该模块仅存在于根
\bin
文件夹中,就不会加载该模块的二进制文件,从而导致
App1
应用程序出错。
可通过以下方法解决这种不一致的继承问题:
- 在
App1
文件夹下放置
\bin
文件夹和其他必要的系统文件夹副本,但需根据应用程序情况判断模块加载是否有益。
- 按照“集合项”部分所述“移除”模块,自 ASP.NET v2.0 起,移除模块后将不再加载,可使用
<remove />
或
<clear />
,使用
<clear />
时需确保添加回站点正常运行所需的模块。
- 使用 ASP.NET v2.0 引入的
inheritInChildApplications
属性,例如:
<location path="" inheritInChildApplications="false">
<system.webServer>
<modules>
<add name="CustomModule" type="..." preCondition="managedHandler" />
</modules>
</system.webServer>
</location>
此设置将仅应用于网站根目录,而不会应用于任何子应用程序。需注意,一个部分不能同时存在于两个位置,对于路径内的每个唯一部分,要么全部继承,要么全部不继承。
9. 锁定机制
服务器管理员通常拥有服务器的完全访问权限,而站点所有者需被隔离在自己的区域,并仅被授予管理站点所需的权限。通过部分、属性和元素锁定是确保这一点的主要方法之一。
使用位置标签可设置配置项,使其不能被覆盖,控制该功能的属性是
overrideMode
,有
Allow
、
Deny
和
Inherit
三个选项。例如,设置
windowsAuthentication
部分不能在路径层次结构中被进一步覆盖:
<location path="Default Web Site" overrideMode="Deny">
<system.webServer>
<security>
<authentication>
<windowsAuthentication>
<providers />
</windowsAuthentication>
</authentication>
</security>
</system.webServer>
</location>
通常在全局配置文件中设置这些锁定,许多部分默认已锁定,但可进行更改以锁定或解锁配置文件的部分内容。
10. childConfig/sourceConfig 属性的使用
通过
childConfig
和
sourceConfig
属性可将配置的部分内容拆分到其他配置文件中,原因如下:
-
安全性
:可将配置部分委托给不同的管理员,并应用 NTFS ACL,使只有必要的用户或角色能够进行更改。
-
可管理性
:将配置拆分为多个部分,可让不同的人管理配置的不同部分,避免相互干扰。
-
部分隔离
:拆分配置可保护部分配置不被无关更改覆盖,对于网站的
web.config
文件尤其有用,因为常见的 FTP 或其他远程部署方法可能会覆盖服务器上通过 IIS 管理器所做的更改。
更新
childConfig
或
sourceConfig
文件不会像更改其他
.config
文件那样导致
AppDomain
回收,这意味着更改不会立即生效,直到下次重新加载配置文件,或你手动“触摸”主配置文件(在不重要的位置添加一个空格并保存文件),从而触发
AppDomain
回收,使配置更改生效。
默认情况下,三个主要的全局配置文件(
applicationHost.config
、
machine.config
和根
web.config
)不使用
childConfig
或
sourceConfig
。需注意,
sourceConfig
在
applicationHost.config
中不起作用,
childConfig
不支持部分的属性值。
11. 配置路径的理解
理解 IIS 7.0 中的配置路径很重要,无论是使用
AppCmd.exe
等工具,还是进行编程开发。与 IIS 6.0 及以前的版本相比,配置路径有了很大变化。
在 IIS 6.0 及以前,配置路径形式为
LM/W3SVC/1/ROOT
(其中 1 是站点 ID),由于整个配置只有一个元数据库文件,工具或编程 API 无需引用配置文件。
在 IIS 7.0 中,由于 ASP.NET 成为重要组成部分,存在多个配置文件,且设置可能存在于多个级别,因此需要一种方法来指定特定设置应应用的位置。新系统中,配置路径的语法如下:
MACHINE/WEBROOT/APPHOST/{Sitename}/{Vdir or App}
其中,
MACHINE
对应
machine.config
,
WEBROOT
对应根
web.config
文件,
APPHOST
对应
applicationHost.config
,引用站点时,
MACHINE/WEBROOT/APPHOST
可选。
有趣的是,此配置路径结构从不直接引用设置,仅引用配置文件和位置标签,这与 IIS 6.0 不同,IIS 6.0 通常需要直接指向属性的完整路径。IIS 7.0 的配置设置是单独进行的。
可以使用部分路径访问特定配置文件,例如
machine.config
的路径为
MACHINE
,
redirection.config
的路径为
MACHINE/REDIRECTION
。
以
AppCmd.exe
为例,默认情况下,目录浏览设置可在站点的
web.config
中设置,若希望将设置应用于
applicationHost.config
中的位置标签,可使用以下命令:
AppCmd.exe Set Config "Default Web Site/" /section:directoryBrowse /enabled:true /COMMIT:MACHINE/WEBROOT/APPHOST
/COMMIT
属性可强制
AppCmd.exe
将设置应用到你指定的位置,此属性可选,通常不需要,但在这种情况下可确保设置直接应用于
applicationHost.config
而非站点的
web.config
文件。
12. 架构扩展性
过去,元数据库没有一致的架构或配置结构,很多内容硬编码到 IIS 中,难以修改或扩展。虽然有
MBSchema.xml
文件保证一定的数据完整性,但仍有改进空间。
IIS 7.0 在这方面有了很大提升,拥有一个包含 IIS 和 .NET 框架架构文件的架构文件夹,这些文件可由 Microsoft、第三方公司或你直接扩展。四个核心架构文件如下:
-
IIS_schema.xml
:涵盖 Windows 进程激活服务(WAS)和 IIS Web 服务器的设置。
-
FX_schema.xml
:涵盖 .NET 框架配置部分。
-
ASPNET_schema.xml
:涵盖 ASP.NET 设置。
-
rscaext.xml
:是运行时状态和控制 API(RSCA)扩展配置的架构文件,与
IIS_Schema.xml
协同工作,添加运行时状态架构。
强烈建议不要直接更改任何原生架构文件,而是使用自己的架构文件进行扩展,这样可确保不会因更改导致 IIS 无法启动,同时保证热修复和升级不会覆盖你所做的更改。
这些架构文件与配置文件中的配置部分共同定义了 IIS 和 .NET 必须遵循的规则和准则,而且可以轻松扩展以包含你所需的任何内容,如网站联系人姓名或电话号码。除了内置架构和可扩展架构,还有动态属性可根据需要动态生成属性及其值,形成了强大的可扩展基础架构。
虽然除了传统的 XML API 外,没有高级的编程方法来获取和设置架构文件,但从文本编辑器进行操作并使用
XCopy
等常用工具进行部署很容易。
下面通过两个示例说明如何扩展架构:
示例一:扩展现有
sites
部分
假设要为网站添加所有者信息,以便自定义工具能识别所有者并获取相关信息。可按以下步骤操作:
1. 在架构文件夹(
%windir%\System32\inetsrv\config\schema
)中创建一个名为
OwnerInfo.xml
的空文本文件。
2. 向文件中添加以下内容:
<configSchema>
<sectionSchema name="system.applicationHost/sites">
<collection addElement="site">
<element name="OwnerInfo" >
<attribute name="name" type="string"/>
<attribute name="email" type="string"/>
<attribute name="role" type="string">
<enum name="Admin" value="0" />
<enum name="Tech" value="1" />
<enum name="Billing" value="3" />
</attribute>
</element>
</collection>
</sectionSchema>
</configSchema>
保存文件后,架构扩展完成,可立即使用。此扩展将添加到现有的
system.applicationHost/sites
架构中。
接下来,使用以下代码将所有者信息写入网站:
Dim SM As New ServerManager
Dim config As Configuration = SM.GetApplicationHostConfiguration
Dim section As ConfigurationSection = _
config.GetSection("system.applicationHost/sites")
Dim mySite As Site = SM.Sites("Default Web Site")
Dim ownerInfo As ConfigurationElement = mySite.GetChildElement("OwnerInfo")
ownerInfo.GetAttribute("name").Value = "Abraham Lincoln"
ownerInfo.GetAttribute("email").Value = "16@whitehouse.gov"
ownerInfo.GetAttribute("role").Value = "Admin"
SM.CommitChanges()
运行程序后,打开
applicationHost.config
的
sites
部分,可看到新设置:
<site name="Default Web Site" id="1">
<application path="/">
<virtualDirectory path="/" physicalPath="%SystemDrive%\inetpub\wwwroot" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:80:" />
</bindings>
<OwnerInfo name="Abraham Lincoln" email="16@whitehouse.gov" role="Admin" />
</site>
示例二:创建新部分
首先,在架构文件夹中添加一个名为
MyCustomSection.xml
的文件,并添加以下内容:
<configSchema>
<sectionSchema name="myCustomSection">
<attribute name="name" type="string" />
<attribute name="Length" type="int" defaultValue="100" />
<attribute name="IsActive" type="bool" defaultValue="true" />
<attribute name="Color" type="enum" defaultValue="Red" >
<enum name="Red" value="0" />
<enum name="Yellow" value="1" />
<enum name="Green" value="3" />
<enum name="Blue" value="4" />
</attribute>
</sectionSchema>
</configSchema>
由于这是一个新部分,还需将其添加到配置文件的
configSections
部分。此示例将其添加到
administration.config
中:
<configuration>
<configSections>
<section name="myCustomSection" />
<section name="moduleProviders" ... />
...
</configSections>
...
</configuration>
以下是设置这四个属性的代码示例:
Dim SM As New ServerManager
Dim config As Configuration = SM.GetAdministrationConfiguration
通过以上内容,我们全面了解了 IIS 7.0 的配置与管理,包括命令执行、配置文件层次结构、集合项处理、位置标签使用、继承问题、锁定机制、配置路径以及架构扩展性等方面,这些知识将帮助我们更好地管理和定制 IIS 7.0 环境。
IIS 7.0 配置与管理全解析
13. 直接配置与编程配置概述
IIS 的管理方式多种多样,常见的有使用 IIS 管理器进行配置和管理,也有人会直接编辑元数据库或开发应用程序来管理 IIS。IIS 7.0 新增了许多特性,深入了解其整个配置结构和可用功能,能让我们更轻松地应对复杂情况。
IIS 7.0 在确保整个架构可扩展和配置方面取得了重大进展,所有编程 API 都能完全访问扩展配置。本章主要分为直接配置和编程配置两大部分。直接配置是指理解配置模型以及许多可以使用简单文本编辑器管理的底层原则。在详细解释配置模型后,我们将探讨编程配置和相关方法,如位于编程 API 核心的新托管 AHAdmin、新的 .NET 托管代码包装器以及 IIS 7.0 Windows 管理规范(WMI),同时还会涵盖 ABO、IIS 6.0 WMI、ADSI 和遗留代码支持等内容。
14. 配置文件层次结构及加载顺序
IIS 7.0 的配置文件层次结构包含多个文件,其加载顺序和相互关系如下:
| 文件 | 路径 | 描述 |
| — | — | — |
|
machine.config
|
%windir%\Microsoft.NET\Framework\<version>\config\
| 包含大部分 .NET 框架的部分和设置,体现了 IIS 与 .NET 框架的紧密结合。 |
|
web.config (root)
|
%windir%\Microsoft.NET\Framework\<version>\config\
| 包含更多特定于 ASP.NET 的部分和设置。 |
|
applicationHost.config
|
%windir%\System32\inetsrv\config (默认)
| 包含 IIS 全局 Web 服务器、配置部分和使用位置标签的站点设置。 |
|
administration.config
|
%windir%\System32\inetsrv\config (默认)
| 包含 IIS 管理器和 IIS 管理器用户的配置。 |
|
redirection.config
|
%windir%\System32\inetsrv\config
| 用于共享配置,允许重新定位
applicationHost.config
和
administration.config
。 |
|
web.config (site)
| 网站根路径 | 包含网站的 ASP.NET 或 IIS 设置,若使用位置标签,可管理子文件夹或文件的设置。 |
|
web.config (application)
| 网站应用程序路径 | 与站点
web.config
文件类似,但可针对单个应用程序。 |
|
Web.config (folder)
| 网站文件夹路径 | 部分
web.config
中的设置可在文件夹级别运行。 |
配置文件的加载顺序如下面的 mermaid 流程图所示:
graph LR
A[machine.config] --> D[全局配置加载]
B[web.config (root)] --> D
C[applicationHost.config] --> D
D --> E[站点 web.config 处理]
在加载过程中,同一设置可能存在于多个位置,此时最后加载的设置将生效。例如:
<!-- applicationHost.config -->
<system.webServer>
...
<directoryBrowse enabled="false" />
...
</system.webServer>
<!-- applicationHost.config location tag -->
<location path="Default Web Site">
<system.webServer>
<directoryBrowse enabled="true" />
</system.webServer>
</location>
<!-- site web.config -->
<system.webServer>
<directoryBrowse enabled="false" />
</system.webServer>
在这个例子中,
directoryBrowse
元素的最终值为
false
。
15. 位置标签的详细应用
位置标签在 IIS 配置中起着核心作用,它允许我们为特定子路径指定唯一设置,而无需在该级别实际存在
web.config
文件。位置标签的
path
属性有多种可能的值,如下表所示:
| 值 | 全局配置示例 | 站点或应用程序示例 | 描述 |
| — | — | — | — |
|
.
(或
""
) |
path="."
|
path="."
| 当前级别。在全局配置文件中,指默认设置;在站点或应用程序的
web.config
文件中,指
web.config
文件所在的位置。 |
|
sitename
|
path="Default Web Site"
| N/A | 指定一个站点,可从任何全局配置文件中使用,不能在站点的
web.config
文件中设置为站点名称。 |
|
application
|
path="Site1/App1"
|
path="App1"
| 在站点或应用程序级别,应用程序名称必须是相对路径。 |
|
vdir
|
path="Site1/Vdir1"
|
path="Vdir1"
| 全局级别需包含站点名称,站点级别不能包含。 |
|
physicaldir
|
path="Site1/PhysicalDir1"
|
path="Physical Dir1"
| 简单文件夹无需是应用程序或虚拟目录,即可应用 IIS 或 ASP.NET 设置,但多数设置被锁定,只能在应用程序根目录外设置。 |
|
file.ext
|
path="Site1/default.aspx"
|
path="login.aspx"
| 可用于配置文件,使用位置标签是配置文件设置的唯一方法。 |
多个位置标签可存在于同一配置文件中,只要不引用相同部分或具有不同的
overrideMode
。创建位置标签时,必须包含到该部分的完整路径,且不能嵌套位置标签。位置标签可用于控制站点或应用程序的设置、集中管理设置、应用设置到文件、锁定部分、禁用继承以及应用默认设置等。
16. 继承问题的深入分析
默认情况下,IIS 中的设置会在子站点、应用程序、文件夹和文件中继承,但在处理 ASP.NET 应用程序时,应用程序文件夹和文件不会跨应用程序边界继承。例如,根站点的
\bin
文件夹中有一个模块,并在
web.config
的
<module>
部分引用,子文件夹
App1
被标记为应用程序,由于
web.config
继承,
App1
应用程序中仍会有该模块的引用,但只要该模块仅存在于根
\bin
文件夹中,就不会加载该模块的二进制文件,从而导致
App1
应用程序出错。
解决这种不一致继承问题的方法有:
- 在
App1
文件夹下放置
\bin
文件夹和其他必要的系统文件夹副本,但需根据应用程序情况判断模块加载是否有益。
- 按照“集合项”部分所述“移除”模块,自 ASP.NET v2.0 起,移除模块后将不再加载,可使用
<remove />
或
<clear />
,使用
<clear />
时需确保添加回站点正常运行所需的模块。
- 使用 ASP.NET v2.0 引入的
inheritInChildApplications
属性,例如:
<location path="" inheritInChildApplications="false">
<system.webServer>
<modules>
<add name="CustomModule" type="..." preCondition="managedHandler" />
</modules>
</system.webServer>
</location>
此设置将仅应用于网站根目录,而不会应用于任何子应用程序。需注意,一个部分不能同时存在于两个位置,对于路径内的每个唯一部分,要么全部继承,要么全部不继承。
17. 锁定机制的实际应用
服务器管理员通常拥有服务器的完全访问权限,而站点所有者需被隔离在自己的区域,并仅被授予管理站点所需的权限。通过部分、属性和元素锁定是确保这一点的主要方法之一。
使用位置标签可设置配置项,使其不能被覆盖,控制该功能的属性是
overrideMode
,有
Allow
、
Deny
和
Inherit
三个选项。例如,设置
windowsAuthentication
部分不能在路径层次结构中被进一步覆盖:
<location path="Default Web Site" overrideMode="Deny">
<system.webServer>
<security>
<authentication>
<windowsAuthentication>
<providers />
</windowsAuthentication>
</authentication>
</security>
</system.webServer>
</location>
通常在全局配置文件中设置这些锁定,许多部分默认已锁定,但可进行更改以锁定或解锁配置文件的部分内容。
18. childConfig/sourceConfig 属性的作用与影响
通过
childConfig
和
sourceConfig
属性可将配置的部分内容拆分到其他配置文件中,这样做有以下好处:
-
安全性
:可将配置部分委托给不同的管理员,并应用 NTFS ACL,使只有必要的用户或角色能够进行更改。
-
可管理性
:将配置拆分为多个部分,可让不同的人管理配置的不同部分,避免相互干扰。
-
部分隔离
:拆分配置可保护部分配置不被无关更改覆盖,对于网站的
web.config
文件尤其有用,因为常见的 FTP 或其他远程部署方法可能会覆盖服务器上通过 IIS 管理器所做的更改。
更新
childConfig
或
sourceConfig
文件不会像更改其他
.config
文件那样导致
AppDomain
回收,这意味着更改不会立即生效,直到下次重新加载配置文件,或你手动“触摸”主配置文件(在不重要的位置添加一个空格并保存文件),从而触发
AppDomain
回收,使配置更改生效。
默认情况下,三个主要的全局配置文件(
applicationHost.config
、
machine.config
和根
web.config
)不使用
childConfig
或
sourceConfig
。需注意,
sourceConfig
在
applicationHost.config
中不起作用,
childConfig
不支持部分的属性值。
19. 配置路径的实际应用
理解 IIS 7.0 中的配置路径对于使用
AppCmd.exe
等工具和进行编程开发至关重要。与 IIS 6.0 及以前的版本相比,配置路径有了很大变化。
在 IIS 6.0 及以前,配置路径形式为
LM/W3SVC/1/ROOT
(其中 1 是站点 ID),由于整个配置只有一个元数据库文件,工具或编程 API 无需引用配置文件。
在 IIS 7.0 中,由于 ASP.NET 成为重要组成部分,存在多个配置文件,且设置可能存在于多个级别,因此需要一种方法来指定特定设置应应用的位置。新系统中,配置路径的语法如下:
MACHINE/WEBROOT/APPHOST/{Sitename}/{Vdir or App}
其中,
MACHINE
对应
machine.config
,
WEBROOT
对应根
web.config
文件,
APPHOST
对应
applicationHost.config
,引用站点时,
MACHINE/WEBROOT/APPHOST
可选。
可以使用部分路径访问特定配置文件,例如
machine.config
的路径为
MACHINE
,
redirection.config
的路径为
MACHINE/REDIRECTION
。以
AppCmd.exe
为例,若要将目录浏览设置应用于
applicationHost.config
中的位置标签,可使用以下命令:
AppCmd.exe Set Config "Default Web Site/" /section:directoryBrowse /enabled:true /COMMIT:MACHINE/WEBROOT/APPHOST
/COMMIT
属性可强制
AppCmd.exe
将设置应用到你指定的位置,此属性可选,通常不需要,但在这种情况下可确保设置直接应用于
applicationHost.config
而非站点的
web.config
文件。
20. 架构扩展性的进一步探讨
IIS 7.0 的架构扩展性为我们提供了强大的定制能力。其架构文件夹包含四个核心架构文件:
-
IIS_schema.xml
:涵盖 Windows 进程激活服务(WAS)和 IIS Web 服务器的设置。
-
FX_schema.xml
:涵盖 .NET 框架配置部分。
-
ASPNET_schema.xml
:涵盖 ASP.NET 设置。
-
rscaext.xml
:是运行时状态和控制 API(RSCA)扩展配置的架构文件,与
IIS_Schema.xml
协同工作,添加运行时状态架构。
强烈建议不要直接更改任何原生架构文件,而是使用自己的架构文件进行扩展,这样可确保不会因更改导致 IIS 无法启动,同时保证热修复和升级不会覆盖你所做的更改。
下面通过两个示例进一步说明如何扩展架构:
示例一:扩展现有
sites
部分
假设要为网站添加所有者信息,可按以下步骤操作:
1. 在架构文件夹(
%windir%\System32\inetsrv\config\schema
)中创建一个名为
OwnerInfo.xml
的空文本文件。
2. 向文件中添加以下内容:
<configSchema>
<sectionSchema name="system.applicationHost/sites">
<collection addElement="site">
<element name="OwnerInfo" >
<attribute name="name" type="string"/>
<attribute name="email" type="string"/>
<attribute name="role" type="string">
<enum name="Admin" value="0" />
<enum name="Tech" value="1" />
<enum name="Billing" value="3" />
</attribute>
</element>
</collection>
</sectionSchema>
</configSchema>
保存文件后,架构扩展完成,可立即使用。接下来,使用以下代码将所有者信息写入网站:
Dim SM As New ServerManager
Dim config As Configuration = SM.GetApplicationHostConfiguration
Dim section As ConfigurationSection = _
config.GetSection("system.applicationHost/sites")
Dim mySite As Site = SM.Sites("Default Web Site")
Dim ownerInfo As ConfigurationElement = mySite.GetChildElement("OwnerInfo")
ownerInfo.GetAttribute("name").Value = "Abraham Lincoln"
ownerInfo.GetAttribute("email").Value = "16@whitehouse.gov"
ownerInfo.GetAttribute("role").Value = "Admin"
SM.CommitChanges()
运行程序后,打开
applicationHost.config
的
sites
部分,可看到新设置:
<site name="Default Web Site" id="1">
<application path="/">
<virtualDirectory path="/" physicalPath="%SystemDrive%\inetpub\wwwroot" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:80:" />
</bindings>
<OwnerInfo name="Abraham Lincoln" email="16@whitehouse.gov" role="Admin" />
</site>
示例二:创建新部分
首先,在架构文件夹中添加一个名为
MyCustomSection.xml
的文件,并添加以下内容:
<configSchema>
<sectionSchema name="myCustomSection">
<attribute name="name" type="string" />
<attribute name="Length" type="int" defaultValue="100" />
<attribute name="IsActive" type="bool" defaultValue="true" />
<attribute name="Color" type="enum" defaultValue="Red" >
<enum name="Red" value="0" />
<enum name="Yellow" value="1" />
<enum name="Green" value="3" />
<enum name="Blue" value="4" />
</attribute>
</sectionSchema>
</configSchema>
由于这是一个新部分,还需将其添加到配置文件的
configSections
部分。此示例将其添加到
administration.config
中:
<configuration>
<configSections>
<section name="myCustomSection" />
<section name="moduleProviders" ... />
...
</configSections>
...
</configuration>
以下是设置这四个属性的代码示例:
Dim SM As New ServerManager
Dim config As Configuration = SM.GetAdministrationConfiguration
综上所述,IIS 7.0 在配置和管理方面提供了丰富的功能和强大的扩展性。通过深入理解配置文件层次结构、位置标签的使用、继承问题的处理、锁定机制、配置路径以及架构扩展性等内容,我们能够更加灵活地管理和定制 IIS 7.0 环境,满足不同的业务需求。无论是小型网站还是大型 Web 应用,IIS 7.0 都能提供稳定、高效的支持。
超级会员免费看
77

被折叠的 条评论
为什么被折叠?



