Label

　　　　　　编辑:　　图片来源:网络

简介

Microsoft ASP.NET 2.0 提供了许多新的功能，这些功能减少了生成强大而复杂的 Web 应用程序所需的时间。可是，生成一个应用程序只是过程的一部分。一旦站点建立，您就必须在应用程序的生命期中部署、监视并维护它。ASP.NET 2.0、Microsoft Internet 信息服务 (IIS) 6.0 和 Microsoft .NET Framework 2.0 用几个新功能解决了这些问题，这些功能使 Web 应用程序的部署、配置、监视和维护比以前更简单。

举例来说，新的编译选项让您安全地在一台生产服务器上部署 ASP.NET 应用程序。一旦部署完毕，没有完全重部署，应用程序就不能被更改。在另一种情况下，您可能需要一个完全开放的部署，在那里可以对生产服务器上的源代码或者 Web 页面直接进行更改。一个可替换的编译选项集也可以用来支持这种情况。最棒的是，任何更改都将在生产应用程序中自动地反映出来。

在配置方面，ASP.NET 2.0 提供了一个内置的管理 Web 站点，它可以使您通过一个安全 Web 界面创建并配置用户、配置数据提供程序，以及执行其他管理选项。

最后，在监视方面，ASP.NET 2.0 扩展了 ASP.NET 1.x 中的可用监视，并为站点计数器、跟踪、调试和健康监视提供更好的支持。

ASP.NET 2.0 中的新功能与 IIS 6.0（ASP.NET 2.0 与 IIS 5.0 也可以一起使用）的功能相结合，为部署、配置和监视您的 Web 应用程序提供了很多选项。无论您是专业的系统管理员，或者是构建小型 Web 站点的玩家，本文都将为您提供如何用 ASP.NET 2.0 和 IIS 6.0 执行 IT 操作的可靠概述。

返回页首

部署

ASP.NET 1.x 和 .NET Framework 为部署 Web 应用程序引入了几个新的机制。与 ASP 部署相比，ASP.NET 部署最值得注意的功能是：

•	无须注册。在 ASP 中，任何外部的 DLL 必须在 Windows 注册表中注册。这个注册需要对 GUID 的仔细管理以避免兼容性问题。.NET 应用程序使用不同的模型来存储代码，它不依赖于 Windows 注册表或 GUID 标识符。
•	无须重新启动。在 ASP 中，如果开发者更新了某个 DLL，站点管理员就不得不停止并重新启动 IIS 实例来获得更改的代码。由于 ASP.NET 的处理模型的缘故，代码更改会被自动监测并加载而无须 IIS 重新启动。
•	更多部署选项。部署 ASP 应用程序需要几个配置步骤，包括虚拟目录的创建和几个组件的注册。另一方面，ASP.NET 应用程序可以通过几个不同的机制来部署，这取决于目标和想要的部署类型。

在本文中，我们要看看 ASP.NET 2.0 与 ASP.NET 1.0 相比如何不同，并展示如何在其生命周期的每个阶段部署 ASP.NET 2.0 应用程序。

为开发部署

Microsoft Visual Studio 2005 包含了一个用于开发 ASP.NET 应用程序的轻量级 Web 服务器。这个 Web 服务器只能为本地请求提供服务，因此对开发来讲是完美的。通过使用这个内置的 Web 服务器，您不再需要在开发机器上使用 IIS 了。您可以使用内置的服务器并获得完全的调试支持，而无须公开任何开发代码，也不会导致管理维护工作量增加。另一个重要的优势是，使用 Visual Studio 2005，任何使用者都可以生成并测试应用程序。您不再需要成为该台计算机上的管理员了。应该注意到的是，仍然必须在 IIS 上部署最终应用程序。

为产品部署

ASP.NET 2.0 应用程序必须部署到一个带有 IIS 5.0 或 6.0 版的服务器上。在本文中，我们将集中考虑部署到 IIS 6.0 上。

部署 .NET Framework 2.0

为了部署 ASP.NET 2.0 应用程序，首先必须在服务器上部署 .NET Framework 2.0。幸运的是，对 .NET Framework 进行了设计，以便不同的版本可以同时存在于相同的服务器上。换句话来说，您可以部署 .NET Framework 的 2.0 版而无须卸载或修改使用任何版本的 Framework 1.x 的任何应用程序。

IIS MMC 管理单元

ASP.NET 2.0 为 IIS 部署了一个特殊的 Microsoft 管理控制台 (MMC) 管理单元，它允许您决定哪些应用程序应该使用哪些版本的 .NET Framework。

图 1. ASP.NET 应用程序的 MMC 显示

MMC IIS 选项卡允许您选择您的应用程序使用哪个版本的 ASP.NET，并显示 Web.config 的位置。

除了管理 Framework 版本，控制台还有一个“编辑配置”按钮，它让您可视化地编辑大多数 Web.config 设置而不必直接操作 Web.config XML 文件。作为管理员，您将发现，这个 MMC 管理单元为配置和管理一台单个服务器上的多个 ASP.NET 应用程序提供了一个非常有用的工具。

返回页首

增强的代码隐藏模型

传统的 ASP 页面包含了设计 (HTML) 和逻辑两种代码。如果没有一个功能丰富的调试环境，调试和编码可读性将随着代码数量增长而变得更加困难。代码隐藏模型将设计方面从逻辑方面分离开来。

代码隐藏功能在 ASP.NET 1.x 中首次被引入。这个模型将您页面的设计方面从逻辑方面分离开来，但是有几个问题随着这个模型出现。代码隐藏类不是在运行时自动编译的，因此每一次更新后都需要项目的重新生成。由于控件声明性地而且以编程方式存在，此模型导致了代码的脆弱，并且不匹配和同步错误的潜在可能性较高。

新的代码隐藏模型利用了局部类。局部类让您可以在不止一个文件中定义类的不同部分。这些文件在编译时被组合。ASP.NET 2.0 消除了控件声明，并允许 Web 表单和代码隐藏类在运行时被编译。

返回页首

编译选项

ASP.NET 2.0 为 Web 应用程序提供了四个不同的编译模型：

•	正常 (ASP.NET 1.x)。在一般的 ASP.NET Web 应用程序中，代码隐藏文件被编译到一个程序集中并存储在 /bin 目录里。Web 页面 (ASPX) 在需要时被编译。对于大多数 Web 站点，这个模型都能正常运行。但是，编译过程使对任何 ASP.NET 页面的第一次请求要比以后的请求慢一些。ASP.NET 2.0 继续支持这种编译模式。
•	批编译。在 ASP.NET 2.0 中，您可以通过一个单个 URL 请求批编译任何应用程序。就像用 ASP.NET 1.x 一样，批编译消除了第一次页面请求的延迟，但是造成了更长的启动周期时间。此外，批编译仍要求代码隐藏文件在预部署后编译。
•	部署预编译。ASP.NET 2.0 的一个新功能允许在部署前对项目进行完全编译。在完全编译中，取决于应用程序的大小和编译设置，所有代码隐藏文件、ASPX 页面、HTML、图形资源和其他后端代码被编译到一个或更多可执行程序集中。这些程序集包含了整个 Web 站点（除了 Web.config）。这种编译方法以移除用于修改 Web 站点 post 部署的所有功能为代价，提供了最佳性能和安全性。如果您正在处理高可见或高安全的 Web 站点，这个选项对最终的部署来说是最佳选择。但是，如果您正在构建一个运行在本地 Intranet 上的小型站点，并且该站点经常变更，完全预编译可能就是矫枉过正了。
•	完全运行时编译。在部署预编译的另一个极端，ASP.NET 2.0 提供了一个新的机制以在运行时编译整个应用程序。就是说，您可以将未编译的代码隐藏文件和任何其他关联的代码放在新的 \code 目录下，并让 ASP.NET 2.0 去创建和维护对将在运行时从这些文件中生成的程序集的引用。以在服务器上存储未编译代码为代价，这个选项提供了在更改 Web 站点内容方面最佳的灵活性。

选择最佳编译选项将取决于您确切的环境和需要。但是，编译模型保持着灵活性。即便您选择使用 \code 目录来存储您的代码隐藏文件，您仍可以使用完全编译方法部署您的应用程序。

有关编译模型的详细信息，请参阅 ASP.NET 2.0 Internals。

限制重新编译

ASP.NET 2.0 的一个精巧功能是，在整个应用程序重新启动前，ASP.NET 运行库在一个应用程序上将只允许固定数量的运行时重新编译。基本上，在运行中，某一数量的重新编译后，ASP.NET 运行库确定整个应用程序可能不再有效。运行库自动关闭应用程序实例并重新加载整个应用程序，而不冒发生错误的风险。

作为系统管理员，您永远都不应担心这个过程，因为它是透明和自动化的。唯一的顾虑是应用程序是否维护会话。如果您已经配置您的应用程序去使用一个“out-of-state”过程或数据库，那么即使应用程序重新启动，它也将自动保持活动会话。

您可以通过调整 web.config 或 machine.config 文件的标记上的 numRecompilesBeforeAppRestart 属性配置允许的重新编译数。

部署应用程序

有几个方法用于手动安装 ASP.NET 应用程序。两个首选方法是：

•

XCOPY。XCOPY 部署允许您将已编译的 .NET 应用程序文件从一台计算机复制到另一台。对于独立的应用程序来说，这个方法是最快又最容易的部署选项。XCOPY 对于开发、测试以及在一些 Web 应用程序方案中最奏效。但是，XCOPY 方法不能够与全局程序集缓存 (GAC) 一起使用，或用于在目标计算机上需要注册或配置的应用程序。在 Web 应用程序方面，如果在生产服务器上已创建并配置了一个虚拟目录，XCOPY 会极其奏效。术语 XCOPY 是指一个执行大量文件转移的 DOS 命令。

•

Microsoft Windows 安装程序 (MSI)。为了自动化虚拟目录设置并且允许重复部署，许多管理员更喜欢传统的安装程序。尽管 MSI 在 .NET 之前就是可用的，但是 Visual Studio 为 .NET 应用程序提供了一个快速创建 MSI 文件的简化的工具。您的 MSI 文件可以在目标计算机上生成代码访问安全性策略、创建桌面图标和菜单项、插入注册表项，并允许对 .NET 应用程序的轻松卸载。对于 ASP.NET 应用程序来说，一个 MSI 文件提供了自动创建虚拟目录的便利，以及自动化任何其他设置任务的机会。MSI 部署对于应用程序对新服务器的初次部署最奏效。

在 ASP.NET 2.0 中，您可以使用这些方法中的任一种，或使用下一节中描述的 FTP 或 SharePoint 通讯选项从 Visual Studio 2005 直接部署。

返回页首

更新应用程序

一旦 ASP.NET 应用程序已经部署，您就可以视您分配给服务器的安全策略而定，用几种不同的方法更新它。

XCOPY

ASP.NET 被设计用来在任何应用程序组件更改时重新加载应用程序。举例来说，如果您将新的 DLL 或 ASPX 页面复制到 Web 服务器，应用程序将自动加载更改的代码。通过简单地将新文件复制到旧文件上，您自动地更新了您的应用程序。因此，XCOPY 给您提供了一种方法，用于执行一次安装到多台 Web 服务器而不必关闭整个网络场。您只需要对每台服务器执行一次交叉复制操作。

MSI

如果您选择用一个 MSI 文件更新，那么您将必须创建一个新的安装包并重新部署。由于 MSI 使用 Microsoft 安装程序框架，您可能不得不暂时关闭您的应用程序以卸载旧版本并重安装新版本。幸运的是，因为 ASP.NET 应用程序在其自己的 CLR 应用程序域中运行，所以您不必重新启动服务器或重新启动 IIS 进程。应用程序只是在 CLR 进程内的新应用程序域中重新启动。

在部署期间，使用 MSI 包来更新您的 ASP.NET 应用程序比使用 XCOPY 有几个优势。对于多台服务器部署，或者贯穿部署、测试、接受和生产几个层次的复杂部署模型，MSI 通常做得最好。

对 FTP、Share Point 和 IIS 的支持

Visual Studio 2005 有对编辑和更新远程 Web 项目的内置支持。您可以使用文件传输协议 (FTP)、Microsoft Share Point 或通过与本地可访问的 IIS 实例直接通讯来更新和维护应用程序。多种方法使您部署和维护应用程序变得简单。

图 2. FTP 维护对话框

举例来说，如果您或使用打开 Web 站点对话框，或使用新 Web 站点对话框，您可以连接到一个 Web 站点并使用 FTP 来传输或更新文件。

别再用 FrontPage

ASP.NET 1.x 应用程序被设计成通过 Microsoft FrontPage 服务器扩展 (FPSE) 与 IIS 集成在一起。但是 FPSE 增加了额外的管理负担和安全风险。许多宿主公司认为 FPSE 是一个“不必要的服务”并禁用了它，从而迫使 ASP.NET 开发者使用其他方法来部署并使用其应用程序。

在 ASP.NET 2.0 中，FPSE 不再是必要或必需的了。由于上面描述的部署和更新选项，Visual Studio 2005 开发者有更多更好的选项来将其代码发布到 Web 服务器上。

返回页首

IIS 配置

当前，大多数 ASP.NET 1.x 应用程序运行在 Microsoft IIS 5.0 上。ASP.NET 2.0 被设计为利用 IIS 6.0 的功能。IIS 6.0 在安装上是安全的，那是因为它是在锁定的状态下配置的，而且除了服务静态 Web 页面外不会做什么。这有助于消除一些拒绝服务攻击，这些攻击是以您甚至不知道正在运行的东西为目标的。您必须手动配置软件来执行更高级的功能，如 ASP 和 ASP.NET 站点服务。当您添加高级功能时，IIS 6.0 会针对潜在的安全风险向您发出警告，并推荐用于配置服务器安全性的最佳方法。同时，IIS 6.0 有更严格的限制和超时设定，这样软件就对外界展现出更少的攻击表面。

从 IIS 5.0 移植

当您从 IIS 5.0 向 IIS 6.0 迁移时，有几个问题可能发生（举例来说，DSN 和 ODBC 连接、ISAPI 应用程序和 COM+ 组件的问题），但是最常见的迁移问题的出现，是因为 IIS 6.0 可以在两个截然不同的操作模式之一中运行（它们被称作应用程序隔离模式）。应用程序隔离通过进程边界来分离应用程序以防止应用程序互相影响。应用程序隔离为两种 IIS 应用程序隔离模式的每一个进行了不同的配置。

•

IIS 5.0 隔离模式。IIS 5.0 隔离模式只应在应用程序依赖 IIS 5.0 的内存模型和进程时使用。您可能已经将 ASP.NET 应用程序配置为使用 IIS 5.0 模型。如果您想继续使用 IIS 5.0 隔离（需要 machine.config 文件的设置），请使用 IIS 5.0 隔离模式。

•

辅助进程隔离模式。辅助进程隔离模式在一个隔离的环境中运行所有应用程序。和 IIS 早期的版本不同，因为当您从一个应用程序池切换到另一个的时候只有很少的处理器指令在运行，所以没有性能计数器。辅助进程隔离模式与大多数现有的 Web 站点和应用程序是兼容的，而且现在是默认设置。只要可能，以辅助进程隔离模式运行 IIS 6.0 以从 IIS 6.0 中增强的性能和安全性中获益。

IIS 6.0 体系结构

图 3. IIS 体系结构比较

关于新 IIS 6.0 体系结构，第一件要注意的事情是，为最大化性能运行在核心层的 HTTP 侦听器和缓存。Web 应用程序的其他部分运行在用户级。

Web 管理服务 (WAS) 作为 Web 服务器的用户模式组件取代了 IISAdmin。WAS 可以监视应用程序以发现延迟进程、停止和重新启动应用程序，并提供包括处理器关系的服务。

每个应用程序都运行在应用程序池的上下文中。一个应用程序池可以包含一个或更多应用程序。一个池中的每个应用程序共享一个主进程 (w3wp.exe)。您可以使用应用程序池将相关应用程序分组并优化资源使用。

返回页首

应用程序可靠性

IIS 6.0 新体系结构的目的是使每个应用程序与其他每个应用程序以及核心 Web 服务器完全隔离。IIS 6.0 允许您实现几个功能来改善应用程序的可靠性。

定期应用程序回收

为了提高应用程序可靠性，IIS 6.0 实现定期进程回收。当某个条件（例如，正常运行时间、请求数量、预定时间、内存消耗）满足时，您的应用程序将自动重新启动。回收应用程序确保您的应用程序是可用的，并且防止恶意应用程序接管系统。应该注意的是，当您的应用程序回收时，您必须创建代码来保持状态。

图 4. 回收辅助进程对话框

Pinging

健康检查 (pinging) 旨在检测辅助进程线程中的任何死锁。每个辅助进程 (W3WP.exe) 线程都被 ping 到。如果进程在指定时间内没有响应，这个进程将被取消（默认），或者您可以配置该进程来执行某一操作。

图 5. 启用 pinging 对话框

崩溃检测和快速失败保护

当一个辅助进程崩溃时 IIS 6.0 可以检测到。如果需要服务中没有中断，IIS 6.0 会自动启动一个新的进程。

图 6. 调整故障转移属性

返回页首

目前在 XML 中的元数据库

IIS 6.0 对元数据库实现了几个关键更改。元数据库是用于存储大部分 IIS 配置设置的内存驻留数据库。IIS 6.0 将格式从专有二进制格式更改为 XML 格式，使得按您指定的需要编辑和配置元数据库更容易。IIS 6.0 允许您编辑元数据库而无须停止您机器上的 IIS 服务。这显著地降低了应用程序的当机时间。

IIS 6.0 实现了元数据资源管理器，让备份和恢复元数据库更加容易 — 即便是备份或存储到不同的机器。这个功能让您创建一个主机器，它可以在另一台机器上被克隆。只要对元数据库做出任何更改，新的元数据历史功能就自动创建备份。

图 7. 元数据库资源管理器

有关移植到 IIS 6.0 和新功能的更多信息，请参阅：Inside IIS 和这个 Microsoft PowerPoint 演示： http://support.microsoft.com/servicedesks/Webcasts/wc112002/WC112002.ppt.

返回页首

管理 Web 应用程序

您将 Web 站点部署在一台生产服务器上之后，您仍须管理此应用程序。特别是，如果您部署了一个使用新的个性化、成员和配置文件功能的 ASP.NET 2.0 应用程序，您将需要确保提供程序被正确配置而且用户以及角色被正确定义。

Web 站点管理工具概述

要简化管理用户的过程，ASP.NET 2.0 提供了一个内置的 Web 站点配置工具。Web 站点管理工具是一个简单的 Web 站点，它只能通过安全连接或直接在本机上访问。借由这个工具，管理员可以通过配置服务（如用户管理、个性化提供程序、安全性和配置文件）来管理应用程序。这个工具也允许您轻松地为应用程序配置计数器、调试和跟踪信息。

图 8. Web 站点管理工具

管理提供程序

Web 站点管理工具使您无须编写任何代码就能管理提供程序。只是通过单击提供程序选项卡，您就可以选择配置、删除或添加新提供程序来存储站点信息。

图 9. 提供程序管理屏幕

在 Beta 1 中，ASP.NET 2.0 Web 应用程序包括一个 Microsoft Access 数据库来承载您所有的应用程序信息 (ASPNETAccessProvider)。未来的版本中，默认的提供程序可能被迁移到 Microsoft SQL Server Express。

当您添加一个新提供程序时，ASP.NET 在 C://inetpub/application_name/data 文件夹中自动生成一个数据库。列表 1 中的代码自动添加到 machine.config 文件中。

列表 1. Machine.config 文件

该数据库包含预定义的表来承载用户、角色、配置文件以及您的站点的附加信息。

图 10. 来自 ASPNET 数据库的示例表

ASP.NET 2.0 提供一个提供程序模型，它允许您使用适用于您的提供程序的任何类型的数据库，但是管理工具只支持 Microsoft Access 和 SQL Server 数据库。

管理用户

Web 站点管理工具的安全性页面让您添加并编辑用户、角色以及访问规则。

图 11. 安全性配置选项

此工具允许您创建角色和用户。通过简单地选择可用角色的复选框，用户就可以被分配到角色。

图 12. 用户管理屏幕

管理其他功能

Web 站点管理工具还允许您存储配置文件和应用程序信息。通过存储一个用户的配置文件信息，您就可以根据用户的首选项来为每个用户显示自定义信息和布局。您可以将信息存储为 .NET 数据类型或自定义数据类型。

图 13. 配置文件属性设置屏幕

应用程序管理屏幕让您可以配置站点统计信息（比如说，计数器）、应用程序的 SMTP 选项、应用程序设置以及调试和跟踪选项。调试区域还允许您设置默认值或自定义错误页面和消息。

返回页首

监视 .NET 应用程序

由于大部分 Web 站点依赖于快速数据传输并且有越来越多的用户，监视 Web 应用程序的性能是有必要的。.NET Framework 1.x 包含许多用于监视应用程序的工具。.NET Framework 2.0 扩展了现有的功能，并包含了几个新功能来帮助您更有效更准确地监视应用程序。

返回页首

调试器可视化

当使用 Microsoft Visual Studio .NET 以前的版本进行调试时，如果负载大小很大或包含 XML，那么有时难以查看 IDE 中变量、属性或对象的负载。Visual Studio 2005 实现了内置的可视化工具，帮助您轻松地查看存储在任何变量中的信息。您可以选择在文本、html 或者 xml 浏览器中查看变量。当数据是html、xml 或者当该值是一个长字符串时，这得查看分配给变量的值变得更加轻松。

图 14：调试器可视化

返回页首

Unicode 转换格式：8 日志记录

IIS 6.0 支持 Unicode 日志记录。UTF-8 代表 Unicode（或 UCS）转换格式、8-bit 编码形式。UTF-8 是用于 Unicode 的传输格式，它适用于许多网络协议和 UNIX 文件系统。使用 UTF-8 允许您将日志结果导入和导出到运行不同语言、操作系统或协议的机器，并确保结果仍然可读。

返回页首

性能计数器

性能计数器是由正在执行的应用程序、服务或操作系统进程发布的多组数据，来帮助诊断和分析吞吐量和瓶颈。Microsoft Windows 2000、Windows XP 和 Microsoft Windows Server 2003 本身就支持计数器。性能计数器是监视的第一线。计数器为您提供信息，帮助您标识低性能的区域，这些信息还可以被用作触发器，来指出是否需要做更多的分析。

图 15. Visual Studio 控件属性窗口

Visual Studio 2005 在属性窗口中有一个选项，无须编写任何代码就可以为您的控件添加简单的性能计数器。您可以实现单击计数器，并通过简单地将属性设置为等于 TRUE 来跟踪页面 URL。

返回页首

事件跟踪

事件跟踪允许您在事件（比如，当用户登录到您的应用程序）激发时收集重要信息。事件跟踪是高度可扩展的，并且只需要很少的系统开销（5% 或更少的 CPU 开销）。下列图表显示了事件跟踪模型：

图 16：事件跟踪模型

事件被通过事件跟踪会话记录下来。这个事件跟踪模型与 ASP.NET 1.x 中提供的事件跟踪模型相同，但是有几个新事件（用于分析、编译和呈现）可用。系统可以支持到 32 个同时事件跟踪会话。在 Windows 2000 上，这些会话中的两个被保留用作特殊的目的。在 Windows XP 上，这些会话中的三个被保留。剩余的会话可以在一般情况下使用。每个事件跟踪会话都维护一组缓冲（称为缓冲池），在那里跟踪会话临时存储事件数据。

控制器

事件跟踪控制器启动和停止事件跟踪会话，管理缓冲池，并获得会话的执行统计信息。会话统计信息包括使用的缓冲区数量、传递的缓冲区数量、丢失的事件和缓冲区数量，以及日志文件（如果使用了它的话）的大小和位置。

使用 Tracerpt.exe 实用工具可以控制事件。Tracerpt.exe 可以生成报告并将所有跟踪信息转储为 .csv 格式。

列表 2. 使用 Tracerpt 实用工具控制事件

tracerpt mylog_000001.etl

提供程序

事件跟踪提供程序负责事件的传递。事件跟踪提供程序注册事件分类，并给每个事件类一个唯一的 GUID，这让类可以与事件侦听器这样的 Windows 服务对话。事件跟踪器注册后，可以通过事件跟踪控制器启用或禁用它。一般来说，如果一个提供程序已经被启用，它会生成事件，但是当它被禁用的时候，就不会生成事件了。这使您能够将事件跟踪添加到不是随时都运行的应用程序中。

使用者

事件跟踪使用者可以选择一个或多个事件跟踪会话作为事件的来源。使用者可以从多个事件跟踪会话请求事件，并且您的系统将按时间顺序返回事件。使用者可以接收存储在日志文件中，或者来自实时传递事件的会话中的事件。您可以指定启动和停止的时间以确保只在指定时间范围内发生的事件被传递。

您可以在操作系统中使用已安装的标准使用者类执行基于事件的操作。标准使用者是简单的定义使用者类的已注册类。当其收到事件通知后，每个标准使用者执行指定的操作。

命令行工具 Logman.exe 可以被用来使用跟踪。logman.exe 实用工具执行与图形化的 perfmon 工具相同的功能。下列代码展示了使用 Logman.exe 您可以多么轻松地创建和更新一个跟踪。

列表 3. 使用 logman.exe 管理事件跟踪

logman create trace ASPNET  "mylog"
logman update trace ASPNET pf events.txt

健康监视

除了跟踪模型，ASP.NET 2.0 还提供了全功能的应用程序监视和健康监视。这个系统是由一个完全可扩展事件模型和一个能将事件发送到多种接收器的事件引擎组成的。举例来说，您可以配置您的 ASP.NET 应用程序来每天发送电子邮件，表明服务器正在运行并且包括可用内存的数量。同样，您可以创建一个链接到未处理异常的健康事件。异常内容、请求标题以及时间和日期都可以被发送到一个错误日志记录数据库。

ASP.NET 2.0 包含了内置的事件，包括心跳、应用程序生存期事件（启动/停止/编译）和错误陷阱事件（未处理异常）。不过，，您可以很容易地在这些基类之上进行构建，以从应用程序重创建并引发您自己的事件。举例来说，您可能创建一个自定义的事件来记录何时第一百个用户单击某一特定的链接。

ASP.NET 2.0 健康监视系统真正强大的功能是，通过 web.config 和 machine.config 文件它是完全可配置的。使用正常的 XML，您能定义事件、定义提供程序（事件接收器），以及将特定的事件发送到特定的提供程序。

创建事件

事件在结构上与异常是类似的。也就是说，除了作为一个消息容器，event 类本身几乎没有功能。在健康监视方面，所有事件都从 Sytstem.Web.Management.WebBaseEvent 继承。不过，您也可以从用于专用目的（如收集 HTTP 请求数据或处理异常）的高级基类派生。

列表 4. 自定义事件

using System;
using System.Web.Management;

public class CustomEvent : WebBaseEvent
{
  public const int EventCode = WebEventCodes.WebExtendedBase + 10;
  public MyEvent(string message, object eventSource) 
                : base(message, eventSource, EventCode)
  { }
}

创建自定义事件的最重要部分是提供一个唯一的 EventCode。所有内置事件代码都在 WebEventCodes 枚举中。自定义事件应该有从 WebEventCodes.WebExtendedBase + 1 开始的数字。除此之外创建自定义事件中的唯一常见任务是正确地初始化事件。

使用事件

虽然内置事件自动激发，但您还是可以将代码添加到应用程序以在任何时候启动自定义事件。

列表 5. 引发一个事件

当您从 ASP.NET 页面引发一个事件时，您只是创建该事件的一个新实例然后执行 Raise() 方法。Raise() 方法将事件实例自动传递到健康监视引擎。然后此引擎将该事件映射到配置文件和提供程序，并将该事件移交给正确的提供程序。提供程序最终将事件传递到正确的接收器。

配置健康监视

健康监视是在 machine.Config 或 Web.Config 文件中的新的区域配置的。您可以配置部分来设置一个周期性报告应用程序状态的 Web 检测信号。您也可以配置应用程序来生成事件，并将该事件通过各种提供程序传递。

配置事件

必须在事件映射区域标识每个事件。事件通过唯一名称和完整类型被标识。事件名称在规则区域是作为链接来使用的。

列表 6. 事件映射区域

ASP.NET 2.0 附带几个内置事件，配置为下列名称：

•	所有事件。所有事件名称捕获任何 WebBaseEvent。这个事件类别是对被健康监视系统捕获的每个事件的一个广泛的 catch-all。
•	检测信号。检测信号事件使用 WebHeartBeatEvent 提供关于 Web 应用程序状态的定期通知。
•	应用程序生存期事件。应用程序生存期事件包括启动和停止应用程序，以及重新编译应用程序的部分或全部。这些事件是基于 WebApplicationLifetimeEvent 的，并且在 lifetime 事件发生时，报告日期、时间和当前的状态。
•	所有错误。所有错误类别收集系统检测到的任何异常或错误。这些事件是基于 WebBaseErrorEvent 的。
•	基础结构错误。使用 WebErrorEvent 捕获与 ASP.NET 运行库或 IIS 相关的错误。这些事件是所有错误类别的子类，并且主要与系统管理员而不是应用程序开发者相关。
•	请求处理错误。在请求期间发生的任何错误或异常都会触发一个 WebRequestErrorEvent。这个事件记录了进入的请求以及与处理该请求相关联的错误。请求处理错误也是所有错误类别的一个子集。
•	所有审核。可使用健康监视系统通过 WebAuditEvent 提供审核尝试。这个事件自动记录 Web 应用程序中活动用户的操作。如果您正在使用模拟，审核事件将帮助您对谁在使用您的应用程序，以及他们是如何在使用保持跟踪。
•	失败审核。WebFailureAuditEvent 是一个特殊的审核事件类型，当一个用户试图使用无效的用户名或密码登录您的 Web 站点时，它就会被触发。当一个对于指定资源用户是无法验证的时候，此事件也会发生。
•	成功审核。WebSuccessAuditEvent 是失败事件的对应，只要用户已验证或执行一些其他需要审核记录的操作就会发生。

自定义事件是易于创建的，尽管您必须向您的应用程序添加代码来引发事件。

配置提供程序

每个提供程序都必须在配置文件中注册。注册一个提供程序需要应用程序的唯一名称和类型。这个类型包含了实际 provider 类的完整强名称 (strong name)。提供程序的名称被用作规则区域中的一个链接。

列表 7. 提供程序

ASP.NET 2.0 附带有 WMI、Windows 事件监视器、SMTP 电子邮件和 SQL Server 数据库的提供程序。通过扩展正确的基类，可以创建自定义提供程序来连接到其他事件接收器。

将事件映射到提供程序

配置健康监视的最后一步是，用规则将事件连接到提供程序。规则提供了在好的事件名称、事件类、提供程序和事件配置文件或者类别之间的一个链接。您也可以使用规则来定义启动特定的事件的一个最短时间间隔。

列表 8. 规则

规则执行由不同属性配置的若干不同任务：

•	name。规则名称是友好名称，它会在事件被发送到接收器时出现。
•	eventName。eventName 映射到一个在区域中配置的事件。
•	provider。提供程序是一个到在区域中配置的提供程序的链接。任何匹配这个规则的事件将通过这个提供程序传递给由该提供程序支持的目标。举例来说，System.Web.Management.SqlWebEventProvider 会自动将事件写入到 SQL Server 数据库。
•	profile。不同的提供程序将配置文件属性作为显示事件的过滤器来使用。举例来说，电子邮件提供程序可能立即为任何带有“紧急”配置文件的事件发送一个消息，但是也可能只发送带有该日“例行”配置文件事件的汇编的日常电子邮件。
•	minInterval。一些事件，如检测信号，必须在最短的时间间隔内激发。您可以使用这个属性来设置最小事件时间间隔。

通过这个配置区域，您可以设置各种健康相关事件，并将事件映射到各种提供程序。举例来说，您可能设置一个检测信号，每 10 分钟发送一个 WMI 事件。同样，您可以为任何未捕获的异常设置一个电子邮件警报。

小结

ASP.NET 2.0、IIS 6.0 和 .NET Framework 2.0 实现了几个新的功能，无论是对专业的 Web 站点管理员还是 Web 站点玩家来说，这些功能让部署、配置、监视和维护 Web 应用程序比以前更加简单。您不仅能使用任何新的部署方法来部署您的应用程序，由于新的编译选项，您还可以决定代码应该如何部署。

内置的管理 Web 站点允许您创建并配置用户、配置数据提供程序，以及通过一个安全 Web 界面执行其他管理选项。同样，ASP.NET MMC 管理单元让您使用一个简单的界面在单个服务器上管理多个 Web 站点。您不必再担心手动编辑配置文件，或者与哪个应用程序使用哪个版本的 Framework 做斗争了。ASP.NET 控制台让您从一个单一的界面控制所有这些项。

最后，在监视方面，ASP.NET 2.0 通过提供对网站计数器、跟踪、调试和健康监视更好的支持，扩展了在 ASP.NET 1.x 中可用的监视。开发者可以为应用程序、页面，甚至页面上的控件创建计数器，而且这些计数器可以从多种来源读取。

ASP.NET 2.0 和 IIS 6.0 结合在一起来提供一个非常灵活而有用的平台，无论您是在部署和承载一个单一的简单应用程序，还是许多复杂的应用程序。

简介

部署

为开发部署

为产品部署

部署 .NET Framework 2.0

IIS MMC 管理单元

增强的代码隐藏模型

编译选项

限制重新编译

部署应用程序

更新应用程序

XCOPY

MSI

对 FTP、Share Point 和 IIS 的支持

别再用 FrontPage

IIS 配置

从 IIS 5.0 移植

IIS 6.0 体系结构

应用程序可靠性

定期应用程序回收

Pinging

崩溃检测和快速失败保护

目前在 XML 中的元数据库

管理 Web 应用程序

Web 站点管理工具概述

管理提供程序

管理用户

管理其他功能

监视 .NET 应用程序

调试器可视化

Unicode 转换格式：8 日志记录

性能计数器

事件跟踪

控制器

提供程序

使用者

健康监视

创建事件

使用事件

配置健康监视

配置事件

配置提供程序

小结

相关书籍