虽然 Microsoft® ASP .NET 的设计者在保持 ASP 应用程序的向后兼容性方面做了大量不懈的努力，但在将 Web 应用程序由 ASP 向 ASP .NET 迁移之前，还是应该了解一下几个关键的问题。在 .NET 平台和 ASP .NET 中对现有技术进行了改进并采用了一些新技术，透彻理解这些技术有利于简化此迁移过程，但这需要经过一段漫长的时间。
本文探讨各方面的变化，以便让用户清楚地了解建立 ASP 应用程序并使其在 ASP .NET 环境中运行所必须进行的一些工作。同时，它还指出了 ASP .NET 的一些新特性，用户可以充分利用这些新特性改进现有的应用程序。但这决不是 ASP .NET 所有新特性的全面介绍，而只是着重探讨一下成功迁移时需考虑的一些问题。
我设想，由于大多数 ASP 应用程序都使用 Microsoft® Visual Basic® Scripting Edition (VBScript)，所以大多数用户都会选择使用 Visual Basic .NET 迁移到 ASP .NET。显然，这不是必需的。但如果决定在迁移的同时更改语言，将需要进行一些额外的工作，而且很可能还会涉及到设计和结构方面的更改。
共存性
在讨论具体的兼容性和迁移问题之前，了解一下 ASP 和 ASP .NET 如何共存非常重要。ASP 和 ASP .NET 应用程序可以同时在服务器上运行，而互不影响。这主要是由于两种技术各自使用不同的文件扩展名（.asp 与 .aspx）和不同的配置模型（配置数据库/注册表与基于 XML 的配置文件）。这两种系统还各自具有相应的处理引擎。
让某个应用程序的一部分运行 ASP，而另一部分运行 ASP .NET，这是完全可能的。如果需要将一个快速发展的大型站点一次一小部分地迁移到 ASP .NET，这种特性将对您大有益处。某些用户可能会说，最好能一次性迁移和部署整个站点。对于某些类型的 Web 应用程序来说也许是如此，但我认为，有许多站点并不能这样：考虑到站点内容和外观的绝对大小、复杂程度以及迅速变化，这种方式非常缺乏灵活性。毕竟，对于一个盈利的网站来说，那些掏腰包的人不可能允许您停止他们的新增功能，而将整个网站迁移到这种热门的新技术。另外，如果把向 ASP .NET 迁移作为一项长期投资，您将希望利用此机会尽可能多地对结构和设计做一些改进。综合这些情况，分阶段的共存性迁移是绝对必要的。
兼容性问题
将应用程序向 ASP .NET 迁移可能不是一件容易的事情；但是，也不应该很困难。ASP .NET 与 ASP 的兼容性非常好，给用户的感觉就好象 ASP .NET 是 ASP 的一个完整翻版。ASP .NET 设计者的最初目标是实现与 ASP 百分之百的向后兼容性，但在随后的工作中，他们不得不改变了这一初衷，以便彻底地改进这一平台。不过不要担心，我们尽可能进行了大量改进，应该不会需要您进行太多的工作。所发生的实际变化可以归纳为下列几类：
核心 API 的变化
结构变化
Visual Basic 语言的变化
与 COM 有关的变化
应用程序配置的变化
状态管理问题
与安全性有关的变化
数据访问
下面将详细讨论上述各个方面的变化。
核心 API 的变化
ASP 的核心 API 由几个固有对象（Request、Response 和 Server 等）及其有关方法组成。除几处简单变化之外，这些 API 在 ASP .NET 下可以继续正常运行。所有变化都与 Request 对象有关，如表 1 所示：
表 1：API 的变化
方法 变化
Request(item) 在 ASP 中，此方法返回字符串数组。在 ASP .NET 中，它返回 NameValueCollection。
Request.QueryString(item) 在 ASP 中，此方法返回字符串数组。在 ASP .NET 中，它返回 NameValueCollection。
Request.Form(item) 在 ASP 中，此方法返回字符串数组。在 ASP .NET 中，它返回 NameValueCollection。
在 ASP .NET 中新增了几个指令。我鼓励您在 ASP .NET 文档中查看一下这些指令，了解它们可以为您的应用程序带来什么样的好处。
生成函数不再有效
开发者指出，在 ASP 中，他们可以使用“生成函数”灵活处理一些问题。“生成函数”基本上是一个子程序，在其主体中嵌入了大量 HTML。例如：
这是正在生成的 HTML 文本。
虽然使用这类函数能够实现非常酷的功能，但 ASP .NET 中不允许使用这类编码。这可能是出于优化性能的考虑。我想您肯定遇到过，像这样将代码与 HTML 混在一起时，有些函数很快就变得可读性极差，而且难以管理。在 ASP .NET 中，实现此目的的最简单方法是调用 Response.Write 来代替 HTML 输出，如下所示：
注意，我说的是“最简单的方法”，但并不一定表示是最佳方法。根据生成代码的复杂程度和数量，使用自定义 Web 控件效果可能更好，这种控件允许您通过编程设置 HTML 属性，并将代码与内容真正分开，使代码可读性更强。
由于 ASP 中的所有类型都是 VARIANT，对于所需的 Date 变量，将根据它们的使用方式进行编译并可以继续使用。但是，使用变量执行某些操作时，由于基本类型已发生变化，所以可能会遇到一些意想不到的问题。在将日期值作为长整型值传递给 COM 对象时，或使用 CLng 对日期类型执行某些计算时，需特别注意。
从 ASP .NET 中调用 COM 对象方法时，或调用自定义 Visual Basic 组件中的 Microsoft® Win32® API 调用时，可能会出现问题。应特别注意需要的实际数据类型，确保传递或计算的值正确。
结构化异常处理
虽然人们所熟悉的 On Error Resume Next 和 On Error Goto 错误处理技术在 Visual Basic .NET 中仍可使用，但它们不再是进行错误处理的最佳方法。Visual Basic 现在具有一种完善的结构化异常处理方法，它使用 Try、Catch 和 Finally 关键字。如果可能，您应该迁移到这种新模式进行错误处理，因为它具有更强大、更一致的应用程序错误处理机制。
与 COM 有关的变化
随着 .NET 框架和 ASP .NET 的诞生，COM 实际上没有发生任何变化。但这并不表示在 ASP .NET 中使用 COM 对象时不必担心和考虑他们的行为。有一些基本情况，您必须了解。
线程模式的变化
ASP .NET 线程模式是多线程单元 (MTA)。这就意味着，对于目前使用的为单线程单元 (STA) 创建的组件，如果不采取额外的措施，将不能在 ASP .NET 中可靠地执行或运行。其中包括但不限于使用 Visual Basic 6.0 及其更低版本创建的所有 COM 组件。作者: tznktg 时间: 2007-10-16 13:08
ASPCOMPAT 属性
您将很高兴听到这样一个消息：仍然可以使用这些 STA 组件，而不需要更改任何代码。您需要做的工作只是在 ASP .NET 网页的 。使用此属性将强制网页以 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 组件上的投入所限，并不总是能够立即做到这一点。
在 ASP 中，所有 Web 应用程序配置信息都存储在系统注册表和 IIS 配置数据库中。由于服务器上经常未安装适当的管理工具，使得查看或修改设置变得非常困难。ASP .NET 引入了一整套全新的配置模型，这套模型以简单的、易读的 XML 文件为基础。每个 ASP .NET 应用程序都有自己的 Web.Config 文件，该文件位于主应用程序目录中。可以通过此文件控制 Web 应用程序的自定义配置、行为和安全性。
做为刷新程序，模拟是指这样一个过程：对象以它所代表的实体的标识执行代码。在 ASP 中，模拟允许您的代码代表通过身份验证的用户运行。或者，用户也可以通过特定标识匿名运行。默认情况下，ASP .NET 不会针对每个请求进行模拟。这一点与 ASP 不同。如果您依赖于这种功能，则需要在 web.config 文件中启用它，如下所示：
数据访问
迁移过程中，需要重点考虑的另一个关键问题是数据访问。随着 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，可以确保所有变量都声明为正确的数据类型。这样做确实需要增加一些额外的工作，但从长期考虑，您将发现还是很值得这样做的。