与 COM 有关的变化
随着 .NET 框架和 ASP .NET 的诞生，COM 实际上没有发生任何变化。但这并不表示在 ASP .NET 中使用 COM 对象时不必担心和考虑他们的行为。有一些基本情况，您必须了解。

线程模式的变化
ASP .NET 线程模式是多线程单元 (MTA)。这就意味着，对于目前使用的为单线程单元 (STA) 创建的组件，如果不采取额外的措施，将不能在 ASP .NET 中可靠地执行或运行。其中包括但不限于使用 Visual Basic 6.0 及其更低版本创建的所有 COM 组件。

ASPCOMPAT 属性
您将很高兴听到这样一个消息：仍然可以使用这些 STA 组件，而不需要更改任何代码。您需要做的工作只是在 ASP .NET 网页的 <%Page> 标记中包含兼容性属性 aspcompat=true，如 <%Page aspcompat=true Language=VB%>。使用此属性将强制网页以 STA 模式执行，从而确保您的组件可以继续正确运行。如果试图使用 STA 组件但没有指定此标记，运行时将会发生异常情况。

将此属性的值设置为 true 时，将允许网页调用 COM+ 1.0 组件，该组件需要访问非管理的 ASP 内置对象。可以通过 ObjectContext 对象进行访问。

如果将此标记的值设为 true，性能会稍微有些下降。建议只在确实需要时才这样做。

早期绑定与后期绑定
在 ASP 中，对 COM 对象的所有调用都是通过 IDispatch 接口进行的。这种行为被称为“后期绑定”，因为对实际对象的调用是在运行时通过 IDispatch 间接处理的。在 ASP .NET 中，只要您愿意，可以继续以这种方式调用您的组件。

Dim Obj As Object
Obj = Server.CreateObject("ProgID")
Obj.MyMethodCall

仍然可以使用这种方式访问您的组件，但这不是首选方式。现在，在 ASP .NET 中，您可以利用早期绑定直接创建对象，如下所示：

Dim Obj As New MyObject
MyObject.MyMethodCall()

使用早期绑定，可以通过类型安全的方式与组件交互。为了在 COM 组件中使用早期绑定，您需要像在 Visual Basic 6.0 项目中添加 COM 引用一样，在项目中添加一个引用。假设您正在使用 Visual Studio .NET，将在 COM 组件之上后台创建一个管理的代理对象，给您的感觉就好像是直接在处理一个 .NET 组件，而不是 COM 组件。

现在，您可能会担心性能问题。由于代理对象而引入了一个额外的层，所以使用 COM 协同操作时确实会存在一些问题。但是，大多数情况下，应该不会遇到什么问题，因为进行协同操作的实际 CPU 指令数仍然远远小于间接 IDispatch 调用的要求。您所得到的将远远超出您所失去的。当然，理想情况是使用最新创建的管理对象，但我们知道，由于我们在 COM 组件上的投入所限，并不总是能够立即做到这一点。

OnStartPage 和 OnEndPage 方法
需要特别注意的是对旧版 OnStartPage 和 OnEndPage 方法的使用。如果您依赖于这些方法访问 ASP 固有对象，将需要使用 ASPCOMPAT 指令和 Server.CreateObject 以早期绑定方式创建组件，如下所示：

Dim Obj As MyObj
Obj = Server.CreateObject(MyObj)
Obj.MyMethodCall()

注意，我们并没有使用“ProgID”，而是以早期绑定方式使用实际类型。为了让这种方式有效，您需要在 Visual Studio 项目中添加 COM 组件引用，这样才能创建早期绑定的包装类。这是唯一必须继续使用 Server.CreateObject 的情况。

COM 总结
表 2 总结了为继续有效使用 COM 组件而必须完成的一些工作。

表 2：旧版 COM 对象的 ASP .NET 设置

COM 组件类型/方法 ASP .NET 设置/过程
自定义 STA（标记为“Apartment”的 Visual Basic 组件或其它组件） 使用 ASPCOMPAT 和早期绑定
自定义 MTA（标记为“Both”或“Free”的 ATL 或自定义 COM 组件） 不使用 ASPCOMPAT，使用早期绑定
固有对象（通过 ObjectContext 访问） 使用 ASPCOMPAT 和早期绑定
OnStartPage 和 OnEndPage 使用 ASPCOMPAT 和 Server.CreateObject(Type)

无论您的组件是否部署在 COM+ 中，都将同样应用这些设置。

应用程序配置的变化
在 ASP 中，所有 Web 应用程序配置信息都存储在系统注册表和 IIS 配置数据库中。由于服务器上经常未安装适当的管理工具，使得查看或修改设置变得非常困难。ASP .NET 引入了一整套全新的配置模型，这套模型以简单的、易读的 XML 文件为基础。每个 ASP .NET 应用程序都有自己的 Web.Config 文件，该文件位于主应用程序目录中。可以通过此文件控制 Web 应用程序的自定义配置、行为和安全性。

如果您与我一样，您可能会通过“Internet 服务管理器”管理单元检查和更改 ASP .NET 应用程序的设置。但是，您必须了解，现在我们拥有两种完全不同的配置模型。除一些安全性设置外，ASP .NET 应用程序将忽略使用 IIS 管理工具配置的其它大部分设置。您需要将这些配置设置保存在 Web.Config 文件中。

有关 .NET 的应用程序配置将在另一篇文章中详细讨论，此处就不详细介绍了。表 3 说明了可以在自己的文件中配置的一些更有意义的设置。记住，还有更多设置。

表 3：Web.Config 设置示例

设置 说明
<appSettings>
配置自定义应用程序设置。
<authentication>
配置 ASP .NET 身份验证支持。
<pages>
标识网页特定的配置设置。
<processModel>
配置 IIS 系统中的 ASP .NET 进程模型设置。
<sessionState>
指定会话状态选项。

在 .NET 基本类库中还有其它一些类可用，它们简化了对这些设置的编程访问。

状态管理
如果应用程序使用 Session 或 Application 固有对象存储状态信息，则在 ASP .NET 中可以继续使用这些对象，而不会出现任何问题。随之带来的好处是，现在提供了更多的状态存储位置选项。

状态管理选项
ASP .NET 中还包含其它一些状态管理模型选项，最终可使您管理不止一个 Web 服务器，并支持通过 Web 场进行状态管理。

可以在 web.config 文件的 <sessionState> 一节中配置状态管理选项，如下所示：

<sessionState
mode="Inproc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=sa;password=" cookieless="false"
timeout="20"
/>

模式属性指定将在何处存储状态信息。可用选项有 Inproc、StateServer、SqlServer 或 Off。

表 4：会话状态存储信息

选项 说明
Inproc 会话状态本地存储在此服务器中（ASP 样式）。
StateServer 会话状态远程（或本地）存储在状态服务进程中。
SqlServer 会话状态存储在 SQL Server 数据库中。
Off 会话状态被禁用。

如果使用这些选项之一，StateConnectionString 和 sqlConnectionString 无疑将成为至关重要的参数。每个应用程序只能使用一个存储选项。

存储 COM 组件
需记住的的一点是，如果您依赖于对 Session 或 Application 对象中旧版 COM 组件的存储引用，将无法在应用程序中使用新的状态存储机制（StateServer 或 SqlServer）。您将需要使用 Inproc。部分原因是对象需要在 .NET 中实现自我串行，很显然，COM 组件无法做到这一点。另一方面，新创建的管理组件可以相对轻松地实现这一点，因此可以使用新的状态存储模式。

性能
当然，就性能而言，每前进一步都将付出相应的代价。但您完全可以相信，大多数情况下，使用 Inproc 依然是最佳选择，其后依次是 StateServer 和 SqlServer。您自己应该对应用程序进行测试，确保选定的选项可以达到您的性能目标。

ASP 和 ASP .NET 之间的共享状态
需要考虑的另外一个重要问题是，虽然应用程序可以同时包含 ASP 和 ASP .NET 网页，但您无法共享固有 Session 或 Application 对象中存储的状态变量。可能需要将这些信息复制到这两个系统中或提出其它自定义解决方案，才能完全迁移您的应用程序。最好的情况是您未使用 Session 和 Application 对象。另一方面，如果您大量使用了这些对象，您需要一直小心谨慎，或许可以提出某种自定义的短期解决方案来共享状态。

与安全性有关的变化
安全性是需要特别注意的另一个重要问题。下面简要介绍了 ASP .NET 安全性系统。有关安全性问题更完整的研究，请参见 ASP .NET 安全性文档。

ASP .NET 安全性主要受 web.config 文件中安全性部分的设置控制。ASP .NET 与 IIS 协同工作，为您的应用程序提供完善的完全性模型。IIS 安全性设置是实际携带并应用于 ASP .NET 应用程序的少数几个应用程序设置，其携带和应用方式与在 ASP .NET 中相似。当然，在很多方面都得到了改进。

身份验证
对于身份验证，ASP .NET 支持表 5 中所示的选项。

表 5：ASP .NET 身份验证选项

类型 说明
Windows ASP .NET 使用 Windows 身份验证。
Forms 基于 Cookie 的自定义登录表单。
Passport 非 Microsoft 提供的 Passport Service。
None 不执行身份验证。

除新增加的 Passport 身份验证选项之外，其它选项都与 ASP 中的选项相同。例如，下列配置对应用程序启用基于 Windows 的身份验证。

<configuration>
<system.web>
<authentication mode="Windows"/>
</system.web>
</configuration>

授权
用户通过身份验证后，将集中考虑允许他们访问哪些资源。在下例中，授予了“jkieley”和“jstegman”访问权限，而其他所有人都被拒绝访问。

<authorization>
<allow users="NORTHAMERICA\jkieley, REDMOND\jstegman"/>
<deny users="*"/>
</authorization>

模拟
做为刷新程序，模拟是指这样一个过程：对象以它所代表的实体的标识执行代码。在 ASP 中，模拟允许您的代码代表通过身份验证的用户运行。或者，用户也可以通过特定标识匿名运行。默认情况下，ASP .NET 不会针对每个请求进行模拟。这一点与 ASP 不同。如果您依赖于这种功能，则需要在 web.config 文件中启用它，如下所示：

<identity>
<impersonation enable = "true"/>
</identity>

数据访问
迁移过程中，需要重点考虑的另一个关键问题是数据访问。随着 ADO .NET 的诞生，现在您具有了一种访问数据的强有力的全新方法。由于数据访问本身就是一个很大的主题，本文就不详细讨论了。大多数情况下，您可以像过去一样继续使用 ADO，但是我极力推荐您了解一下 ADO .NET，并通过它改善 ASP .NET 应用程序中的数据访问方法。

准备向 ASP .NET 迁移
现在您已了解了可能会遇到的大多数问题，您可能会想：目前我需要做好哪些准备工作以备将来最终迁移到 ASP .NET 呢？目前确实需要完成几项工作，以确保将来的迁移过程顺利进行。其中的许多建议对您的 ASP 代码大有益处，即使目前不打算向 ASP .NET 迁移。

使用 Option Explicit
这始终是一个不错的建议，但至今仍然有许多人没有使用它。通过使用 Option Explicit，强制在 ASP 中声明变量，您至少可以控制在何处定义每个对象以及如何使用变量。迁移到 ASP .NET 之后，我建议使用 Option Strict。在 Visual Basic .NET 中，默认使用 Option Explicit，但是使用更具强制性的 Option Strict，可以确保所有变量都声明为正确的数据类型。这样做确实需要增加一些额外的工作，但从长期考虑，您将发现还是很值得这样做的。

避免使用默认属性
我们前面已讨论过，不再允许使用默认属性。显式访问属性并不是什么难事。它将增强代码的可读性，而且可以在将来节省您的时间。

使用括号和 Call 关键字
正如本文前面详细讨论过的，应尽可能使用括号和 Call 语句。在 ASP .NET 中，将强制使用括号。现在使用 Call 语句有助于您熟悉一些规则，为将来的工作打好基础。

避免嵌套的包含文件
这一点可能说起来容易做起来难，但还是应尽可能避免嵌套包含文件。我的意思是说，应该努力避免在包含文件中包括其它包含文件。随着时间的推移，可能会碰到的一种情况是，您的代码不再依赖于在其它某处的包含文件中定义的全局变量，您需要访问的原因仅仅是因为其中嵌套了包含您真正需要的全局变量的另一个文件。

向 ASP .NET 迁移时，您很有可能会将全局变量和程序迁移到类库中，这种情况下，如果您清楚地了解每个对象的访问位置，迁移起来就很容易。您不需要将一些对象移来移去，也不需要更改多个文件中相同的那些程序名称。

将实用函数合并到单个文件中
迁移过程中的一个策略是将服务器端包含文件中包含的所有实用函数和代码迁移到 Visual Basic 或 C# 类库中。这样，您最终可以将所有代码放到所属对象中，这一点与多解释的 ASP 文件不同。提前组织好代码，可以节省将来的迁移时间。理论上讲，您应该可以将子程序组合到逻辑文件中，从而使您可以轻松地创建一组 VB 或 C# 类。这些函数可能应位于 COM 对象中。

如果服务器端包含文件中存在一大堆全局变量或常量，也最好考虑将他们组合到单个文件中。一旦迁移到 ASP .NET 后，您就可以轻松创建一个类来存放全局或常量数据。这将使系统更干净、更易维护。

尽可能将代码与内容分开
这又是一件说起来比做起来容易的工作，但是您应该尽量将代码与 HTML 内容分开。清理一下主体中即有代码、又有脚本的那些函数。这样做使您处于非常有利的位置，可以充分利用代码--无论怎么说，这是 ASP .NET 中的最佳模式。

不要在 <% %> 块声明函数
ASP .NET 不支持在 <% %> 块声明函数。应该在 <script> 块进行声明。有关此技术的示例，请参阅本文前面的结构变化一节。

避免使用生成函数
如前所述，应该尽量避免使用“生成函数”。如果现在可以更改或准备代码，应在构造这类函数时使用 Response.Write 块。

显式释放资源（调用 Close 方法）
确保对使用的对象和资源中存在的 close() 或清理方法进行显式调用。我们都知道，Visual Basic 和 VBScript 在清理方面的容错能力很强。通常情况下，他们能够立即清理对象。但迁移到 .NET 后，您将无法准确掌握对象何时会被清理，就像您无法确定垃圾堆中的垃圾何时会被清理一样。如果您能够显式清理和释放资源，最好显式地进行清理和释放。

避免混用语言
应该尽量避免在同一网页中混用服务器端 VBScript 和 JScript。一般而言，这是一种不太明智的编程方式。而且向 ASP .NET 迁移时还会存在问题，因为由于采用了新的编译模式，每个网页只要求一种内嵌 <% %> 语言。但仍然可以使用过去的方式生成客户端脚本。

总结
正如我们已经了解的，在向 ASP .NET 迁移应用程序之前，有许多问题需要考虑。我在此文中归纳了迁移前后会发生的大多数变化，这应该能使您的迁移过程变得相对简单一些。

如果您拥有一个大型站点，完成此进程之后，您可能会对遇到并修正了如此多的死代码、无效代码以及所有 Bug 而惊奇不已。另外，通常您还可以充分利用 ASP .NET 和 .NET 平台中大量强大的新增功能。

Jim Kieley 是 Microsoft Consulting Services 的高级顾问。从 .NET 发展初期，Jim 就一直与 Visual Studio 组密切合作，而且他还是早期创建 ASP .NET 和 .NET 框架应用程序的用户之一。您可以通过下列电子邮件地址与 Jim 联系：jkieleymicrosoft.com