配置和检测

由 Microsoft

注意

自本文撰写以来，ASP.NET 成员资格提供程序已被 ASP.NET Identity 取代。 强烈建议更新应用以使用 ASP.NET 标识 平台，而不是本文撰写时介绍的成员资格提供程序。 ASP.NET 标识比 ASP.NET 成员身份系统具有许多优势，包括：

• 性能更好
• 改进了可扩展性和可测试性
• 支持 OAuth、OpenID Connect 和双因素身份验证
• 基于声明的标识支持
• 更好地与 ASP.Net Core 的互操作性

ASP.NET 2.0 中的配置和检测发生了重大更改。 新的 ASP.NET 配置 API 允许以编程方式进行配置更改。 此外，存在许多新的配置设置，允许新的配置和检测。

ASP.NET 2.0 中的配置和检测发生了重大更改。 新的 ASP.NET 配置 API 允许以编程方式进行配置更改。 此外，存在许多新的配置设置，允许新的配置和检测。

在本模块中，我们将讨论配置 API ASP.NET，因为它与读取和写入 ASP.NET 配置文件有关，我们还将介绍 ASP.NET 检测。 我们还将介绍 ASP.NET 跟踪中提供的新功能。

ASP.NET 配置 API

ASP.NET 配置 API 允许使用单个编程接口开发、部署和管理应用程序配置数据。 可以使用配置 API 以编程方式开发和修改完整的 ASP.NET 配置，而无需直接编辑配置文件中的 XML。 此外，还可以在开发的控制台应用程序和脚本、基于 Web 的管理工具和 Microsoft 管理控制台 (MMC) 管理单元中使用配置 API。

以下两个配置管理工具使用配置 API，并包含在 .NET Framework 版本 2.0 中：

• ASP.NET MMC 管理单元，它使用配置 API 来简化管理任务，提供来自配置层次结构所有级别的本地配置数据的集成视图。
• 网站管理工具，可用于管理本地和远程应用程序（包括托管站点）的配置设置。

ASP.NET 配置 API 包含一组 ASP.NET 管理对象，可用于以编程方式配置网站和应用程序。 管理对象作为.NET Framework类库实现。 配置 API 编程模型通过在编译时强制实施数据类型来帮助确保代码的一致性和可靠性。 为了更轻松地管理应用程序配置，配置 API 允许你以单个集合的形式查看从配置层次结构中的所有点合并的数据，而不是将数据作为来自不同配置文件的单独集合查看。 此外，配置 API 使你能够操作整个应用程序配置，而无需直接编辑配置文件中的 XML。 最后，API 通过支持管理工具（如网站管理工具）来简化配置任务。 配置 API 通过支持在计算机上创建配置文件并跨多台计算机运行配置脚本来简化部署。

注意

配置 API 不支持创建 IIS 应用程序。

使用本地和远程配置设置

Configuration 对象表示应用于特定物理实体（如计算机）或逻辑实体（如应用程序或网站）的配置设置的合并视图。 指定的逻辑实体可以存在于本地计算机或远程服务器上。 如果指定实体不存在配置文件，则 Configuration 对象表示Machine.config文件定义的默认配置设置。

可以使用以下类中的一种打开的配置方法获取 Configuration 对象：

1. 如果实体是客户端应用程序，则为 ConfigurationManager 类。
2. 如果实体是 Web 应用程序，则为 WebConfigurationManager 类。

这些方法将返回 Configuration 对象，该对象反过来又提供处理基础配置文件所需的方法和属性。 可以访问这些文件进行读取或写入。

正在读取

使用 GetSection 或 GetSectionGroup 方法读取配置信息。 读取的用户或进程必须对层次结构中的所有配置文件具有读取权限。

注意

如果使用采用 path 参数的静态 GetSection 方法，则 path 参数必须引用运行代码的应用程序。 否则，将忽略 参数，并返回当前正在运行的应用程序的配置信息。

写入

使用其中一个 Save 方法写入配置信息。 写入的用户或进程必须具有对当前配置层次结构级别的配置文件和目录的写入权限，以及对层次结构中所有配置文件的读取权限。

若要生成表示指定实体的继承配置设置的配置文件，请使用以下保存配置方法之一：

1. 用于创建新配置文件的 Save 方法。
2. 用于在另一个位置生成新配置文件的 SaveAs 方法。

配置类和命名空间

许多配置类和方法彼此相似。 下表介绍了最常用的配置类和命名空间。

配置类或命名空间	说明
System.Configuration 命名空间	包含所有.NET Framework应用程序的main配置类。 节处理程序类用于从 GetSection 和 GetSectionGroup 等方法获取节的配置数据。 这两种方法是非静态的。
System.Configuration.Configuration 类	表示计算机、应用程序、Web 目录或其他资源的一组配置数据。 此类包含有用的方法，如 GetSection 和 GetSectionGroup，用于更新配置设置和获取对节和节组的引用。 此类用作获取设计时配置数据的方法的返回类型，例如 WebConfigurationManager 和 ConfigurationManager 类的方法。
System.Web.Configuration 命名空间	包含 ASP.NET 配置设置中定义的 ASP.NET 配置节的节处理程序类。 节处理程序类用于从 GetSection 和 GetSectionGroup 等方法获取节的配置数据。
System.Web.Configuration.WebConfigurationManager 类	提供用于获取对运行时和设计时配置设置的引用的有用方法。 这些方法使用 System.Configuration.Configuration 类作为返回类型。 可以互换使用此类的静态 GetSection 方法或 System.Configuration.ConfigurationManager 类的非静态 GetSection 方法。 对于 Web 应用程序配置，建议使用 System.Web.Configuration.WebConfigurationManager 类，而不是 System.Configuration.ConfigurationManager 类。
System.Configuration.Provider 命名空间	提供一种自定义和扩展配置提供程序的方法。 这是配置系统中所有提供程序类的基类。
System.Web.Management 命名空间	包含用于管理和监视 Web 应用运行状况的类和接口。 严格地说，此命名空间不被视为配置 API 的一部分。 例如，跟踪和事件触发是由此命名空间中的类完成的。
System.Management.Instrumentation 命名空间	提供检测应用程序所需的类，以便通过 Windows Management Instrumentation (WMI) 向潜在使用者公开其管理信息和事件。 ASP.NET 运行状况监视使用 WMI 传递事件。 严格地说，此命名空间不被视为配置 API 的一部分。

从 ASP.NET 配置文件读取

WebConfigurationManager 类是用于从 ASP.NET 配置文件读取的核心类。 从本质上讲，读取 ASP.NET 配置文件有三个步骤：

1. 使用 OpenWebConfiguration 方法获取 Configuration 对象。
2. 获取对配置文件中所需节的引用。
3. 从配置文件中读取所需的信息。

Configuration 对象表示不表示特定的配置文件。 相反，它表示计算机、应用程序或网站的配置的合并视图。 以下代码示例实例化一个 Configuration 对象，该对象表示名为 ProductInfo 的 Web 应用程序的配置。

Configuration config = WebConfigurationManager.OpenWebConfiguration("/ProductInfo);

注意

请注意，如果 /ProductInfo 路径不存在，上述代码将返回 machine.config 文件中指定的默认配置。

获得 Configuration 对象后，可以使用 GetSection 或 GetSectionGroup 方法钻取配置设置。 以下示例获取对上述 ProductInfo 应用程序的模拟设置的引用：

Configuration config =
    WebConfigurationManager.OpenWebConfiguration("/ProductInfo);
IdentitySection section =
   (IdentitySection)config.GetSection("system.web/identity");

写入 ASP.NET 配置文件

与从配置文件读取时一样，WebConfigurationManager 类是写入 Asp.NET 配置文件的核心。 写入配置文件还有三个步骤，ASP.NET 配置文件。

1. 使用 OpenWebConfiguration 方法获取 Configuration 对象。
2. 获取对配置文件中所需节的引用。
3. 使用 Save 或 SaveAs 方法从配置文件中写入所需的信息。

以下代码将编译>元素的 <debug 属性更改为 false：

System.Configuration.Configuration updateWebConfig =
    System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("/webApp");

System.Web.Configuration.CompilationSection compilation =
    updateWebConfig.GetSection("system.web/compilation")
    as System.Web.Configuration.CompilationSection;

compilation.Debug = false;

if (!compilation.SectionInformation.IsLocked) {
    updateWebConfig.Save();
    Response.Write("Save Success!");
} else {
    Response.Write("Save Failed!");
}

执行此代码时，对于 webApp 应用程序的web.config文件，编译>元素的 debug 属性<将设置为 false。

System.Web.Management 命名空间

System.Web.Management 命名空间提供用于管理和监视 ASP.NET 应用程序的运行状况的类和接口。

日志记录是通过定义将事件与提供程序关联的规则来实现的。 规则定义发送到提供程序的事件类型。 可记录以下基本事件：

WebBaseEvent	所有事件的基事件类。 包含所有事件的必需属性，例如事件代码、事件详细信息代码、引发事件的日期和时间、序列号、事件消息和事件详细信息。
WebManagementEvent	管理事件的基事件类，例如应用程序生存期、请求、错误和审核事件。
WebHeartbeatEvent	应用程序定期生成的事件，用于捕获有用的运行时状态信息。
WebAuditEvent	安全审核事件的基类，用于标记授权失败、解密失败 等条件。
WebRequestEvent	所有信息性请求事件的基类。
WebBaseErrorEvent	指示错误条件的所有事件的基类。

可用的提供程序类型允许将事件输出发送到 事件查看器、SQL Server、Windows Management Instrumentation (WMI) 和电子邮件。 预配置的提供程序和事件映射减少了记录事件输出所需的工作量。

ASP.NET 2.0 使用现成的事件日志提供程序根据启动和停止的应用程序域记录事件，以及记录任何未经处理的异常。 这有助于涵盖一些基本方案。 例如，假设应用程序引发异常，但用户不会保存错误，并且你无法重现错误。 使用默认的事件日志规则，你将能够收集异常和堆栈信息，以便更好地了解发生的错误类型。 另一个示例适用于应用程序正在丢失会话状态。 在这种情况下，可以在事件日志中查看，以确定应用程序域是否正在回收，以及应用程序域首先停止的原因。

此外，运行状况监视系统是可扩展的。 例如，可以定义自定义 Web 事件，在应用程序中触发它们，然后定义一个规则以将事件信息发送到提供程序（如电子邮件）。 这使你可以轻松地将检测绑定到运行状况监视提供程序。 再举一例，每次处理订单时，都可以触发事件，并设置一个规则，将每个事件发送到SQL Server数据库。 当用户连续多次登录失败时，还可以触发事件，并将事件设置为使用基于电子邮件的提供程序。

默认提供程序和事件的配置存储在全局Web.config文件中。 全局Web.config文件将存储在 Machine.config 文件中的所有基于 Web 的设置存储在 ASP.NET 1x 中。 全局Web.config文件位于以下目录中：

%windir%\Microsoft.Net\Framework\v2.0.*\config\Web.config

<全局Web.config文件的 healthMonitoring> 部分提供默认配置设置。 可以通过在应用程序的 Web.config 文件中实现 <healthMonitoring> 部分来替代这些设置或配置自己的设置。

<全局Web.config文件的 healthMonitoring> 部分包含以下项：

providers	包含为事件查看器、WMI 和SQL Server设置的提供程序。
eventMappings	包含各种 WebBase 类的映射。 如果生成自己的事件类，则可以扩展此列表。 生成自己的事件类比向其发送信息的提供程序更精细。 例如，可以将未经处理的异常配置为发送到SQL Server，同时将自己的自定义事件发送到电子邮件。
rules	将 eventMappings 链接到提供程序。
缓冲	与SQL Server和电子邮件提供商一起使用，以确定将事件刷新到提供程序的频率。

下面是全局Web.config文件中的代码示例。

<healthMonitoring>
  <!-- Event Log Provider being added. -->
  <providers>
    <add name="EventLogProvider"
         type="System.Web.Management.EventLogWebEventProvider,
               System.Web,Version=2.0.0.0,Culture=neutral,
               PublicKeyToken=b03f5f7f11d50a3a" />
  </providers>
  <!-- Event mapping provides a friendly name to the
events based on the WebBaseErrorEvent class. -->
  <eventMappings>
    <add name="All Errors"
         type="System.Web.Management.WebBaseErrorEvent,
               System.Web,Version=2.0.0.0,Culture=neutral,
               PublicKeyToken=b03f5f7f11d50a3a"
          startEventCode="0" endEventCode="2147483647" />
  </eventMappings>
  <!-- Rule tying the "All Errors" event mapping to the EventLog Provider. -->
  <rules>
    <add name="All Errors Default" eventName="All Errors"
         provider="EventLogProvider"
         profile="Default" minInstances="1"
         maxLimit="Infinite" minInterval="00:01:00" custom="" />
  </rules>
</healthMonitoring>

如何存储事件以事件查看器

如前所述，事件查看器中记录事件的提供程序是在全局Web.config文件中配置的。 默认情况下，将记录基于 WebBaseErrorEvent 和 WebFailureAuditEvent 的所有事件。 可以添加其他规则以将其他信息记录到事件日志。 例如，如果要记录 (所有事件 ，即基于 WebBaseEvent) 的每个事件，可以将以下规则添加到Web.config文件：

<healthMonitoring>
    <rules>
        <add name="All Events" eventName="All Events"
             provider="EventLogProvider" profile="Critical" />
    </rules>
</healthMonitoring>

此规则会将 “所有事件” 事件映射链接到事件日志提供程序。 eventMapping 和 提供程序都包含在全局Web.config文件中。

如何存储事件以SQL Server

此方法使用 ASPNETDB 数据库，该数据库由 Aspnet_regsql.exe 工具生成。 默认提供程序使用 LocalSqlServer 连接字符串，该连接字符串使用 App_data 文件夹中的基于文件的数据库或 SQL Server 的本地 SQLExpress 实例。 LocalSqlServer 连接字符串和 SqlProvider 都在全局Web.config文件中配置。

全局Web.config文件中的 LocalSqlServer 连接字符串如下所示：

<connectionStrings>
    <add name="LocalSqlServer"
         connectionString="data source=.\SQLEXPRESS;
         Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;
         User Instance=true"
         providerName="System.Data.SqlClient" />
</connectionStrings>

如果要使用另一个SQL Server实例，则需要使用 Aspnet_regsql.exe 工具，该工具可在 %windir%\Microsoft.Net\Framework\v2.0.* 文件夹中找到。 使用 Aspnet_regsql.exe 工具在 SQL Server 实例上生成自定义 ASPNETDB 数据库，然后将连接字符串添加到应用程序配置文件，然后使用新的连接字符串添加提供程序。 创建 ASPNETDB 数据库后，需要设置规则以将 eventMapping 链接到 sqlProvider。

无论是使用默认的 SqlProvider 还是配置自己的提供程序，都需要添加将提供程序与事件映射链接的规则。 以下规则将上面创建的新提供程序链接到 “所有事件” 事件映射。 此规则将基于 WebBaseEvent 记录所有事件，并将其发送到将使用 MYASPNETDB 连接字符串的 MySqlWebEventProvider。 以下代码添加一个规则，用于将提供程序与事件映射链接：

<healthMonitoring>
    <rules>
        <add name="All Events" eventName="All Events"
        provider="MySqlWebEventProvider" profile="Critical"/>
    </rules>
</healthMonitoring>

如果只想将错误发送到SQL Server，可以添加以下规则：

<add name="All Errors"
    eventName="All Errors"
    provider="MySqlWebEventProvider"
    profile="Critical"/>

如何将事件转发到 WMI

还可以将事件转发到 WMI。 默认情况下，WMI 提供程序是在全局Web.config文件中配置的。

下面的代码示例添加一个规则，用于将事件转发到 WMI：

<providers>
    <add name="WmiWebEventProvider"
      type="System.Web.Management.WmiWebEventProvider,System.Web,
         Version=2.0.0.0,Culture=neutral,
         PublicKeyToken=b03f5f7f11d50a3a" />
</providers>

需要添加规则以将 eventMapping 关联到提供程序，还需要添加 WMI 侦听器应用程序来侦听事件。 下面的代码示例添加一个规则，用于将 WMI 提供程序链接到 “所有事件” 事件映射：

<rules>
    <add name="All Events"
      eventName="All Events" provider="WmiWebEventProvider"
        profile="Critical" />
</rules>

如何将事件转发到电子邮件

还可以将事件转发到电子邮件。 请注意映射到电子邮件提供商的事件规则，因为可能会无意中向自己发送大量可能更适合SQL Server或事件日志的信息。 有两个电子邮件提供商：SimpleMailWebEventProvider 和 TemplatedMailWebEventProvider。 每个属性具有相同的配置属性，“template”和“detailedTemplateErrors”属性除外，这两个属性仅在 TemplatedMailWebEventProvider 上可用。

注意

这两个电子邮件提供商都没有为你配置。 需要将它们添加到Web.config文件。

这两个电子邮件提供程序之间的main区别在于 SimpleMailWebEventProvider 在无法修改的通用模板中发送电子邮件。 示例Web.config文件使用以下规则将此电子邮件提供程序添加到配置的提供程序列表中：

<add name="mySimple-mailWebEventProvider"
     type="System.Web.Management.Simple-mailWebEventProvider"
     to="e-mail@foo.com" from="e-mail@foo.com"
     maxMessagesPerNotification="1" maxEventsPerMessage="10"
     buffer="true" bufferMode="Critical Notification"
     subjectPrefix="Web Events"/>

还添加了以下规则，将电子邮件提供程序绑定到 “所有事件” 事件映射：

<add name="All Events" eventName="All Events"
    provider="mySimple-mailWebEventProvider" profile="Critical"/>

ASP.NET 2.0 跟踪

ASP.NET 2.0 中跟踪有三个主要增强功能。

1. 集成跟踪功能
2. 以编程方式访问跟踪消息
3. 改进了应用程序级跟踪

集成跟踪功能

现在可以将 System.Diagnostics.Trace 类发出的消息路由到 ASP.NET 跟踪输出，并将 ASP.NET 跟踪发出的消息路由到 System.Diagnostics.Trace。 还可以将 ASP.NET 检测事件转发到 System.Diagnostics.Trace。 此功能由跟踪>元素的新 writeToDiagnosticsTrace 属性<提供。 如果此布尔值为 true，ASP.NET 跟踪消息将转发到 System.Diagnostics 跟踪基础结构，供注册以显示跟踪消息的任何侦听器使用。

以编程方式访问跟踪消息

ASP.NET 2.0 允许通过 TraceContextRecord 类和 TraceRecords 集合以编程方式访问所有跟踪消息。 访问跟踪消息的最有效方法是注册 TraceContextEventHandler 委托， (ASP.NET 2.0) 中新增的，以处理新的 TraceFinished 事件。 然后，可以根据需要循环访问跟踪消息。

以下代码示例对此进行了说明：

void Page_Load(object sender, EventArgs e) {
    // Register a handler for the TraceFinished event.
    Trace.TraceFinished += new
        TraceContextEventHandler(this.OnTraceFinished);
    // Write a trace message.
    Trace.Write("Web Forms Infrastructure Methods", 
      "USERMESSAGE: Page_Load complete.");
}

// A TraceContextEventHandler for the TraceFinished event.
void OnTraceFinished(object sender, TraceContextEventArgs e) {
    TraceContextRecord r = null;
    // Iterate through the collection of trace records and write
    // them to the response stream.
    foreach (object o in e.TraceRecords) {
        r = (TraceContextRecord)o;
        Response.Write(String.Format("trace message: {0} <BR>",
        r.Message));
    }
}

在上面的示例中，我循环访问 TraceRecords 集合，然后将每条消息写入响应流。

改进了Application-Level跟踪

通过引入跟踪元素的新 mostRecent 属性 <，改进了应用程序级跟踪> 。 此属性指定是否显示最新的应用程序级跟踪输出，以及是否丢弃超出 requestLimit 指示的限制的较旧跟踪数据。 如果为 false，则会为请求显示跟踪数据，直到达到 requestLimit 属性。

ASP.NET 命令行工具

有几个命令行工具可帮助配置 ASP.NET。 ASP.NET 开发人员应熟悉aspnet_regiis.exe工具。 ASP.NET 2.0 提供了另外三个命令行工具来帮助配置。

以下命令行工具可用：

工具	使用
aspnet_regiis.exe	允许向 IIS 注册 ASP.NET。 ASP.NET 2.0 附带了两个版本的此工具，一个版本用于框架文件夹) 中的 32 位系统 (，另一个用于 Framework64 文件夹中 (的 64 位系统。) 64 位版本将不会安装在 32 位操作系统上。
aspnet_regsql.exe	ASP.NET SQL Server 注册工具用于创建 Microsoft SQL Server 数据库，供 ASP.NET 中的SQL Server提供程序使用，或从现有数据库中添加或删除选项。 Aspnet_regsql.exe文件位于 Web 服务器上的 [drive：]\WINDOWS\Microsoft.NET\Framework\versionNumber 文件夹中。
aspnet_regbrowsers.exe	ASP.NET 浏览器注册工具将所有系统范围的浏览器定义分析并编译为程序集，并将程序集安装到全局程序集缓存中。 该工具使用浏览器定义文件 (。BROWSER 文件从.NET Framework浏览器子目录) 。 可以在 %SystemRoot%\Microsoft.NET\Framework\version\ 目录中找到该工具。
aspnet_compiler.exe	使用 ASP.NET 编译工具可以就地或部署到目标位置（如生产服务器）来编译 ASP.NET Web 应用程序。 就地编译有助于应用程序性能，因为最终用户在编译应用程序时不会在第一次请求应用程序时遇到延迟。

由于 aspnet_regiis.exe 工具对 ASP.NET 2.0 并不不熟悉，因此我们不会在此处对其进行讨论。

ASP.NET SQL Server注册工具 - aspnet_regsql.exe

可以使用 ASP.NET SQL Server 注册工具设置多种类型的选项。 可以指定 SQL 连接，指定哪些 ASP.NET 应用程序服务使用SQL Server来管理信息，指示哪个数据库或表用于 SQL 缓存依赖项，以及添加或删除对使用SQL Server来存储过程和会话状态的支持。

多个 ASP.NET 应用程序服务依赖于提供程序来管理从数据源存储和检索数据。 每个提供程序特定于数据源。 ASP.NET 包括以下 ASP.NET 功能的SQL Server提供程序：

• SqlMembershipProvider 类) (成员身份。
• 角色管理 (SqlRoleProvider 类) 。
• (SqlProfileProvider 类) 配置文件。
• Web 部件个性化 (SqlPersonalizationProvider 类) 。
• (SqlWebEventProvider 类的 Web 事件) 。

安装 ASP.NET 时，服务器的Machine.config文件包括为依赖于提供程序的每个 ASP.NET 功能指定SQL Server提供程序的配置元素。 默认情况下，这些提供程序配置为连接到 SQL Server Express 2005 的本地用户实例。 如果更改提供程序使用的默认连接字符串，则必须使用 Aspnet_regsql.exe 为所选功能安装 SQL Server 数据库和数据库元素，然后才能使用计算机配置中配置的任何 ASP.NET 功能。 如果使用 SQL 注册工具指定的数据库尚不存在 (aspnetdb 将是默认数据库（如果未在命令行) 上指定数据库），则当前用户必须有权在 SQL Server 中创建数据库以及在数据库中创建架构元素。

SQL 缓存依赖项

ASP.NET 输出缓存的高级功能是 SQL 缓存依赖项。 SQL 缓存依赖项支持两种不同的操作模式：一种使用表轮询的 ASP.NET 实现，另一种模式使用 SQL Server 2005 的查询通知功能。 SQL 注册工具可用于配置表轮询操作模式。

会话状态

默认情况下，会话状态值和信息存储在 ASP.NET 进程中的内存中。 或者，可以将会话数据存储在SQL Server数据库中，该数据库中可以由多个 Web 服务器共享。 如果使用 SQL 注册工具为会话状态指定的数据库尚不存在，则当前用户必须有权在 SQL Server中创建数据库以及在数据库中创建架构元素。 如果数据库确实存在，则当前用户必须有权在现有数据库中创建架构元素。

若要在 SQL Server 上安装会话状态数据库，请运行 Aspnet_regsql.exe 工具，并使用 命令提供以下信息：

• 使用 -S 选项SQL Server实例的名称。
• 有权在运行SQL Server的计算机上创建数据库的帐户的登录凭据。 使用 -E 选项使用当前登录的用户，或使用 -U 选项指定用户 ID 和 -P 选项以指定密码。
• 用于添加会话状态数据库的 -ssadd 命令行选项。

默认情况下，不能使用 Aspnet_regsql.exe 工具在运行 SQL Server 2005 Express Edition 的计算机上安装会话状态数据库。

ASP.NET 浏览器注册工具 - aspnet_regbrowsers.exe

在 ASP.NET 版本 1.1 中，Machine.config文件包含名为 <browserCaps 的部分>。 本部分包含一系列 XML 条目，这些条目基于正则表达式为各种浏览器定义配置。 对于 ASP.NET 版本 2.0，为新的 。BROWSER 文件使用 XML 条目定义特定浏览器的参数。 通过添加新的 来添加新浏览器的信息。浏览器文件到位于系统上 %SystemRoot%\Microsoft.NET\Framework\version\CONFIG\Browser 的文件夹。

由于应用程序不会在每次需要浏览器信息时读取.config文件，因此可以创建新的 。BROWSER 文件并运行Aspnet_regbrowsers.exe，以向程序集添加所需的更改。 这允许服务器立即访问新的浏览器信息，因此无需关闭任何应用程序即可获取信息。 应用程序可以通过当前 HttpRequest 的 Browser 属性访问浏览器功能。

运行 aspnet_regbrowser.exe 时，以下选项可用：

选项	说明
-?	在命令窗口中显示Aspnet_regbbrowsers.exe帮助文本。
-i	创建运行时浏览器功能程序集，并将其安装在全局程序集缓存中。
-u	从全局程序集缓存中卸载运行时浏览器功能程序集。

ASP.NET 编译工具 - aspnet_compiler.exe

ASP.NET 编译工具可通过两种常规方式使用：用于就地编译和部署编译，其中指定了目标输出目录。

就地编译应用程序

ASP.NET 编译工具可以就地编译应用程序，即模拟向应用程序发出多个请求的行为，从而导致定期编译。 预编译网站的用户不会在第一次请求时编译页面而遇到延迟。

就地预编译网站时，以下各项适用：

• 站点保留其文件和目录结构。
• 必须具有服务器上站点使用的所有编程语言的编译器。
• 如果任何文件编译失败，则整个站点编译失败。

向应用程序添加新的源文件后，还可以就地重新编译应用程序。 该工具仅编译新的或更改的文件，除非包含 -c 选项。

注意

编译包含嵌套应用程序的应用程序不会编译嵌套应用程序。 嵌套应用程序必须单独编译。

编译要部署的应用程序

通过指定 targetDir 参数，将应用程序编译为部署 (编译到目标位置) 。 targetDir 可以是 Web 应用程序的最终位置，也可以进一步部署已编译的应用程序。 使用 -u 选项可编译应用程序，以便无需重新编译即可更改已编译应用程序中的某些文件。 Aspnet_compiler.exe区分静态和动态文件类型，并在创建生成的应用程序时以不同的方式处理它们。

• 静态文件类型是没有关联的编译器或生成提供程序的文件类型，例如，其命名的文件具有 .css、.gif、.htm、.html、.jpg、.js 等扩展名。 这些文件只需复制到目标位置，并保留其在目录结构中的相对位置。
• 动态文件类型是具有关联编译器或生成提供程序的文件类型，包括具有 ASP.NET 特定文件扩展名的文件，例如 .asax、.ascx、.ashx、.aspx、.browser、.master 等。 ASP.NET 编译工具从这些文件生成程序集。 如果省略 -u 选项，该工具还会创建文件扩展名为 的文件。已编译，将原始源文件映射到其程序集。 为了确保保留应用程序源的目录结构，该工具会在目标应用程序的相应位置生成占位符文件。

必须使用 -u 选项来指示可以修改已编译应用程序的内容。 否则，后续修改将被忽略或导致运行时错误。

下表描述了包含 -u 选项时 ASP.NET 编译工具如何处理不同的文件类型。

文件类型	编译器操作
.ascx、.aspx、.master	这些文件拆分为标记和源代码，其中包括代码隐藏文件和包含在脚本 runat=“server”>元素中的任何<代码。 源代码编译为程序集，其名称派生自哈希算法，程序集放置在 Bin 目录中。 任何内联代码（即括在 <% 和 %> 括号之间的代码）都包含在标记中，但不编译。 将创建与源文件同名的新文件，以包含标记并放置在相应的输出目录中。
.ashx、.asmx	这些文件未编译，会按原样移动到输出目录，并且不会编译。 如果希望编译处理程序代码，请将代码放入 App_Code 目录中的源代码文件中。
.cs、.vb、.jsl、.cpp (不包括前面列出的文件类型的代码隐藏文件)	这些文件被编译并作为资源包含在引用它们的程序集中。 源文件不会复制到输出目录。 如果未引用代码文件，则不会对其进行编译。
自定义文件类型	这些文件未编译。 这些文件将复制到相应的输出目录。
App_Code子目录中的源代码文件	这些文件编译为程序集并放置在 Bin 目录中。
App_GlobalResources 子目录中的 .resx 和 .resource 文件	这些文件编译为程序集并放置在 Bin 目录中。 不会在 main 输出目录下创建App_GlobalResources子目录，并且不会将源目录中的 .resx 或 .resources 文件复制到输出目录。
App_LocalResources子目录中的 .resx 和 .resource 文件	这些文件不会编译，并且会复制到相应的输出目录。
App_Themes 子目录中的 .skin 文件	不会编译 .skin 文件和静态主题文件，并且会复制到相应的输出目录。
.browser Web.config 静态文件类型 Bin 目录中已存在的程序集	这些文件按原样复制到输出目录。

下表介绍了省略 -u 选项时 ASP.NET 编译工具如何处理不同的文件类型。

文件类型	编译器操作
.aspx、.asmx、.ashx、.master	这些文件拆分为标记和源代码，其中包括代码隐藏文件和包含在脚本 runat=“server”>元素中的任何<代码。 源代码编译为程序集，其名称派生自哈希算法。 生成的程序集放置在 Bin 目录中。 任何内联代码（即括在 <% 和 %> 括号之间的代码）都包含在标记中，但不编译。 编译器创建新文件以包含与源文件同名的标记。 这些生成的文件放置在 Bin 目录中。 编译器还会创建与源文件同名但扩展名为 的文件。包含映射信息的 COMPILED。 。已编译的文件放置在与源文件的原始位置对应的输出目录中。
.ascx	这些文件拆分为标记和源代码。 源代码编译为程序集并放置在 Bin 目录中，其名称派生自哈希算法。 不生成标记文件。
.cs、.vb、.jsl、.cpp (不包括前面列出的文件类型的代码隐藏文件)	由从 .ascx、.ashx 或 .aspx 文件生成的程序集引用的源代码编译为程序集并放置在 Bin 目录中。 不会复制任何源文件。
自定义文件类型	这些文件的编译类似于动态文件。 根据它们所基于的文件类型，编译器可以将映射文件放置在输出目录中。
App_Code子目录中的文件	此子目录中的源代码文件编译为程序集并放置在 Bin 目录中。
App_GlobalResources子目录中的文件	这些文件编译为程序集并放置在 Bin 目录中。 未在 main 输出目录下创建App_GlobalResources子目录。 如果配置文件指定 appliesTo=“All”，则会将 .resx 和 .resources 文件复制到输出目录。 如果 BuildProvider 引用它们，则不会复制它们。
App_LocalResources子目录中的 .resx 和 .resource 文件	这些文件编译为具有唯一名称的程序集，并放置在 Bin 目录中。 不会将 .resx 或 .resource 文件复制到输出目录。
App_Themes 子目录中的 .skin 文件	主题编译为程序集并放置在 Bin 目录中。 存根文件是为 .skin 文件创建的，并放置在相应的输出目录中。 (静态文件（如 .css) ）复制到输出目录。
.browser Web.config 静态文件类型 Bin 目录中已存在的程序集	这些文件按原样复制到输出目录。

固定程序集名称

某些方案（如使用 MSI Windows Installer 部署 Web 应用程序）需要使用一致的文件名和内容，以及一致的目录结构来标识程序集或更新的配置设置。 在这些情况下，可以使用 -fixednames 选项指定 ASP.NET 编译工具应为每个源文件编译程序集，而不是使用 将多个页面编译为程序集的 。 这可能会导致大量程序集，因此，如果担心可伸缩性，应谨慎使用此选项。

强名称编译

提供了 -aptca、 -delaysign、 -keycontainer 和 -keyfile 选项，以便你可以使用 Aspnet_compiler.exe 创建强名称程序集，而无需单独使用 强名称工具 (Sn.exe) 。 这些选项分别对应于 AllowPartiallyTrustedCallersAttribute、 AssemblyDelaySignAttribute、 AssemblyKeyNameAttribute 和 AssemblyKeyFileAttribute。

这些属性的讨论不在本课程的讨论范围内。

实验室

以下每个实验室都基于前面的实验室构建。 需要按顺序执行这些操作。

实验室 1：使用配置 API

1. 创建名为 mod9lab 的新网站。
2. 将新的 Web 配置文件添加到站点。
3. 将以下内容添加到 web.config 文件：

<authorization>
    <deny users="?"/>
</authorization>

<identity impersonate="true"/>

这将确保你有权保存对web.config文件的更改。

1. 将新的 Label 控件添加到 Default.aspx，并将 ID 更改为 lblDebugStatus。
2. 将新的 Button 控件添加到 Default.aspx。
3. 将按钮控件的 ID 更改为 btnToggleDebug ，将“文本”更改为 “切换调试状态”。
4. 打开 Default.aspx 代码隐藏文件的代码视图，并为 System.Web.Configuration 添加 using 语句，如下所示：

using System.Web.Configuration;

1. 将两个私有变量和一个Page_Init方法添加到 类，如下所示：

public partial class _Default : System.Web.UI.Page {
    private bool _debugStatus;
    private CompilationSection compilation;
    private Configuration config;
    protected void Page_Init(object sender, EventArgs e) {
        config = WebConfigurationManager.OpenWebConfiguration("/mod9lab");
        compilation =
            (CompilationSection)config.GetSection("system.web/compilation");
        _debugStatus = compilation.Debug;
    }
}

1. 将以下代码添加到Page_Load：

lblDebugStatus.Text = "Debug set to: " + _debugStatus.ToString();

1. 保存并浏览 default.aspx。 请注意，Label 控件显示当前调试状态。
2. 双击设计器中的 Button 控件，并将以下代码添加到 Button 控件的 Click 事件：

compilation.Debug = !_debugStatus;
config.Save();
lblDebugStatus.Text = "Debug set to: " + compilation.Debug.ToString();

1. 保存并浏览 default.aspx，然后单击按钮。
2. 单击每个按钮后打开web.config文件，并观察编译>部分中的<调试属性。

实验室 2：记录应用程序重启

在本实验室中，你将创建代码，以便在事件查看器切换应用程序关闭、启动和重新编译的日志记录。

1. 将 DropDownList 添加到 default.aspx，并将 ID 更改为 ddlLogAppEvents。
2. 将 DropDownList 的 AutoPostBack 属性设置为 true。
3. 将三项添加到 DropDownList 的 Items 集合。 使第一项的文本选择值和值 -1。 将第二项的“文本”和“值”设置为“True”，并将第三项的“文本”和“值”设置为“False”。
4. 将新的 Label 添加到 default.aspx。 将 ID 更改为 lblLogAppEvents。
5. 打开 default.aspx 的代码隐藏视图，并为 HealthMonitoringSection 类型的变量添加新声明，如下所示：

public partial class _Default : System.Web.UI.Page {
    private bool _debugStatus;
    private CompilationSection compilation;
    private Configuration config;

    // new variable below
    private HealthMonitoringSection health;
}

1. 将以下代码添加到 Page_Init 中的现有代码：

health = (HealthMonitoringSection)config.GetSection("system.web/healthMonitoring");

1. 双击 DropDownList 并将以下代码添加到 SelectedIndexChanged 事件：

if (ddlLogAppEvents.SelectedValue != "-1") {
    if (Convert.ToBoolean(ddlLogAppEvents.SelectedValue)) {
        RuleSettings appRules = new
        RuleSettings("AppRestartEvents",
        "Application Lifetime Events",
        "EventLogProvider");
        health.Rules.Add(appRules);
        config.Save();
    } else {
        health.Rules.Remove("AppRestartEvents");
        config.Save();
    }
}

1. 浏览 default.aspx。

2. 将下拉列表设置为 False。

3. 清除事件查看器中的应用程序日志。

4. 单击按钮可更改应用程序的 Debug 属性。

5. 刷新事件查看器中的应用程序日志。

   1. 是否记录了任何事件？
   2. 为什么是或为什么不是？

6. 将下拉列表设置为 True。

7. 单击按钮切换应用程序的 Debug 属性。

8. 刷新应用程序登录事件查看器。

   1. 是否记录了任何事件？
   2. 应用关闭的原因是什么？

9. 尝试打开和关闭日志记录，并查看对 web.config 文件所做的更改。

详细信息：

ASP.NET 2.0 的提供程序模型允许你创建自己的提供程序，不仅可用于应用程序检测，还可用于许多其他用途以及成员身份、配置文件等。有关编写自定义提供程序以将应用程序事件记录到文本文件的详细信息，请访问 此链接。