通过避免下列10个常见ASP.NET缺陷使网站平稳运行上

ASP.NET 成功的其中一个原因在于它降低了 Web 开发人员的门槛。即便您不是计算机科学博士也可以编写 ASP.NET 代码。我在工作中遇到的许多 ASP.NET 开发人员都是自学成材的，他们在编写 C# 或 Visual Basic? 之前都在编写 Microsoft? Excel? 电子表格。现在，他们在编写 Web 应用程序，总的来说，他们所做的工作值得表扬。

　　但是与能力随之而来的还有责任，即使是经验丰富的 ASP.NET 开发人员也难免会出错。在多年的 ASP.NET 项目咨询工作中，我发现某些错误特别容易导致缺陷不断发生。其中某些错误会影响性能。其他错误会抑制可伸缩性。有些错误还会使开发团队耗费宝贵的时间来跟踪错误和意外的行为。

　　下面是会导致 ASP.NET 生产应用程序的发布过程中出现问题的 10 个缺陷以及可避免它们的方法。所有示例均来自我对真实的公司构建真实的 Web 应用程序的亲身体验，在某些情况下，我会通过介绍 ASP.NET 开发团队在开发过程中遇到的一些问题来提供相关的背景。

　　LoadControl 和输出缓存

　　极少有不使用用户控件的 ASP.NET 应用程序。在出现母版页之前，开发人员使用用户控件来提取公用内容，如页眉和页脚。即使在 ASP.NET 2.0 中，用户控件也提供了有效的方法来封装内容和行为以及将页面分为多个区域，这些区域的缓存能力可以独立于作为整体的页面进行控制（一种称为段缓存的特殊输出缓存形式）。

　　用户控件可以采用声明的方式加载，也可以强制加载。强制加载依赖于 Page.LoadControl，它实例化用户控件并返回控件引用。如果用户控件包含自定义类型的成员（例如，公共属性），则您可以转换该引用并从您的代码访问自定义成员。图 1 中的用户控件实现名为 BackColor 的属性。以下代码加载用户控件并向 BackColor 分配一个值：
protected void Page_Load(object sender, EventArgs e){// 加载用户控件并将其添加到页面中Control control = LoadControl("~/MyUserControl.ascx");PlaceHolder1.Controls.Add(control);// 设置其背景色((MyUserControl)control).BackColor = Color.Yellow;}

　　以上代码实际上很简单，但却是一个等待粗心的开发人员掉进去的陷阱。您能找出其中的破绽吗？

　　如果您猜到该问题与输出缓存有关，那么您是正确的。正如您所看到的一样，上述代码示例编译和运行都正常，但是如果尝试将以下语句（完全合法）添加到 MyUserControl.ascx 中：

　　<%@ OutputCache Duration="5" VaryByParam="None" %>

　　则当您下一次运行该页面时，您将看到 InvalidCastException (oh joy!) 和以下错误消息：

　　“无法将类型为‘System.Web.UI.PartialCachingControl’的对象转换为类型‘MyUserControl’。”

　　因此，此代码在没有 OutputCache 指令时运行正常，但如果添加了 OutputCache 指令就会出错。ASP.NET 不应该以这种方式运行。页面（和控件）对于输出缓存应该是不可知的。那么，这代表什么意思？

　　问题在于为用户控件启用输出缓存时，LoadControl 不再返回对控件实例的引用；相反，它返回对 PartialCachingControl 实例的引用，而 PartialCachingControl 可能会也可能不会包装控件实例，具体取决于控件的输出是否被缓存。因此，如果开发人员调用 LoadControl 以动态加载用户控件并且为了访问控件特定的方法和属性而转换控件引用，他们必须注意进行该操作的方式，以便不管是否具有 OutputCache 指令，代码都可以运行
图 2 说明动态加载用户控件以及转换返回的控件引用的正确方法。以下是其工作原理概要：

　　? 如果 ASCX 文件缺少 OutputCache 指令，则 LoadControl 返回一个 MyUserControl 引用。Page_Load 将该引用转换为 MyUserControl 并设置控件的 BackColor 属性。

　　? 如果 ASCX 文件包括一个 OutputCache 指令并且控件的输出没有被缓存，则 LoadControl 返回一个对 PartialCachingControl 的引用，此 PartialCachingControl 的 CachedControl 属性包含对基础 MyUserControl 的引用。Page_Load 将 PartialCachingControl.CachedControl 转换为 MyUserControl 并设置该控件的 BackColor 属性。

　　? 如果 ASCX 文件包括一个 OutputCache 指令并且控件的输出被缓存，则 LoadControl 返回一个对 PartialCachingControl（其 CachedControl 属性为空）的引用。注意，Page_Load 不再继续执行操作。无法设置控件的 BackColor 属性，因为该控件的输出来源于输出缓存。换句话说，根本没有要设置属性的 MyUserControl。

　　不管 .ascx 文件中是否具有 OutputCache 指令，图 2中的代码都将运行。虽然看起来复杂一点，但它会避免烦人的错误。简单并不总是代表易于维护。

　　返回页首

　　会话和输出缓存

　　谈到输出缓存，ASP.NET 1.1 和 ASP.NET 2.0 都存在一个潜在的问题，该问题会影响在 Windows Server? 2003 和 IIS 6.0 上运行的服务器中的输出缓存页。我曾经亲眼看到该问题在 ASP.NET 生产服务器中出现过两次，这两次都是通过关闭输出缓冲来解决的。后来我了解到有一个比禁用输出缓存更好的解决方案。以下是我第一次遇到该问题时的情况。

　　当时的情况是这样的，某个网站（我们在此称为 Contoso.com，它在小型 ASP.NET Web 领域中运行公共电子商务应用程序）与我的团队联系，抱怨他们遇到了“跨线程”错误。使用 Contoso.com 网站的客户常常突然丢失已经输入的数据，但却看到另一用户的相关数据。稍做分析即发现，跨线程这个描述并不准确；“跨会话”错误更为贴切。看起来 Contoso.com 是在会话状态中存储数据的，由于某些原因，用户会偶尔随机地连接到其他用户的会话
　我的一个团队成员编写了一个诊断工具，用来将每个 HTTP 请求和响应的关键要素（包括 Cookie 标头）记录到日志中。然后，他将该工具安装在 Contoso.com 的 Web 服务器上，并让其运行了几天。结果非常明显。大概每 100000 个请求中会发生一次这样的情况：ASP.NET 正确地为全新会话分配一个会话 ID 并返回 Set-Cookie 标头中的会话 ID。然后，它会在下一个紧相邻的请求中返回相同的会话 ID（即，相同的 Set-Cookie 标头），即使该请求已经与一个有效的会话相关联并且正确提交了 Cookie 中的会话 ID。实际上，ASP.NET 是随机将用户从他们自己的会话中切换出去并将他们连接到其他会话。

　　我们很惊讶，于是开始寻找原因。我们首先检查了 Contoso.com 的源代码，让我们感到欣慰的是，问题不在那。接着，为了确保问题与应用程序宿主在 Web 领域无关，我们只保留一个服务器在运行，而关闭了所有其他服务器。问题仍然存在，这并不意外，因为我们的日志显示匹配的 Set-Cookie 标头绝不会来自两个不同的服务器。ASP.NET 意外地生成了重复的会话 ID，这令人难以置信，因为它使用 .NET Framework RNGCryptoServiceProvider 类生成这些 ID，并且会话 ID 的长度足以确保相同的 ID 决不会生成两次（至少在下一个万亿年内不会生成两次）。除此之外，即使 RNGCryptoServiceProvider 错误地生成了重复的随机数字，也无法解释 ASP.NET 为何不可思议地将有效的会话 ID 替换为新的 ID（不唯一）。

　　凭直觉，我们决定看一下输出缓存。当 OutputCacheModule 缓存 HTTP 响应时，它必须小心不要缓存了 Set-Cookie 标头；否则，包含新会话 ID 的缓存响应会将缓存响应的所有接收者（以及其请求生成了缓存响应的用户）连接到同一会话。我们检查了源代码；Contoso.com 在两个页面中启用了输出缓存。我们关闭了输出缓存。结果，应用程序运行数天而没有发生一个跨会话问题。此后，它运行了两年多都没有发生任何错误。在具有不同应用程序和一组不同 Web 服务器的另一家公司中，我们看到完全相同的问题也消失了。就像在 Contoso.com 一样，消除输出缓存就能解决问题
Microsoft 后来确认此行为源于 OutputCacheModule 中的问题。（当您阅读本文时，可能已经发布了更新。）当 ASP.NET 与 IIS 6.0 一起使用并且启用内核模式缓存时，OutputCacheModule 有时无法从它传递给 Http.sys 的缓存响应中删除 Set-Cookie 标头。下面是导致出现错误的特定事件顺序：

　　? 最近没有访问网站（因此也没有对应的会话）的用户请求一个启用了输出缓存的页面，但是其输出当前在缓存中不可用。

　　? 该请求执行用于访问用户最新创建的会话的代码，从而导致会话 ID Cookie 在响应的 Set-Cookie 标头中返回。

　　? OutputCacheModule 向 Http.sys 提供输出，但是无法从响应中删除 Set-Cookie 标头。

　　? Http.sys 在后续的请求中返回缓存响应，误将其他用户连接到会话。

　　故事的寓意又是什么呢?会话状态和内核模式输出缓存不能混合使用。如果您在启用输出缓存的页中使用会话状态，并且应用程序在 IIS 6.0 上运行，则您需要关闭内核模式输出缓存。您仍将受益于输出缓存，但是因为内核模式输出缓存比普通输出缓存快得多，所以缓存不会同样有效。有关此问题的详细信息，请参见 support.microsoft.com/kb/917072。

　　您可以通过在页面的 OutputCache 指令中包含 VaryByParam="*" 属性来关闭单个页面的内核模式输出缓存，虽然这样做可能导致内存需求骤增。另一种更安全的方法是通过在 web.config 中包含下列元素来关闭整个应用程序的内核模式缓存：

　　<httpRuntime enableKernelOutputCache="false" />

　　您还可以使用注册表设置来全局性地禁用内核模式输出缓存，即禁用全部服务器的内核模式输出缓存。有关详细信息，请参见 support.microsoft.com/kb/820129