与 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 说明了可以在自己的文件中配置的一些更