ASP向ASP.AET迁移要注意的问题

存储 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 的身份验证。

授权

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

模拟

做为刷新程序，模拟是指这样一个过程：对象以它所代表的实体的标识执行代码。在 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，可以确保所有变量都声明为正确的数据类型。这样做确实需要增加一些额外的工作，但从长期考虑，您将发现还是很值得这样做的。

避免使用默认属性

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

使用括号和 Call 关键字

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

避免嵌套的包含文件

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

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

将实用函数合并到单个文件中

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

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

尽可能将代码与内容分开

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

不要在块声明函数

ASP .NET 不支持在 块声明函数。