在 64 位 Windows Server 2003 上将经典 ASP 逐步迁移到 .NET答案

【问题标题】：Migrating Classic ASP progressively to .NET on Windows Server 2003, 64-bit在 64 位 Windows Server 2003 上将经典 ASP 逐步迁移到 .NET
【发布时间】：2012-07-20 15:13:33
【问题描述】：

我有一个相当大的 ASP 站点，它专门使用 VBScript（无 COM 组件）在 64 位 Windows Server 2003 的 IIS 上的 32 位空间中运行。您可以在此处查看架构的粗略草图：

我想开始将它迁移到 ASP.NET，但我的迫切需要是在一个我可以开始使用它的地方访问数据库，以便与驻留在同一服务器上的其他 C# 和 .NET 应用程序一起使用（编译为 32- VS2008 位）。

我的想法是创建 C# .dll，然后从具有互操作性的 ASP 代码中调用它们，当我迁移时，我将完成数据部分。

Interop 对性能有何影响？我最多可能有大约 200 人在几个小时的时间内点击应用程序提交数据库。我的当前设置没有容量或性能问题。

我在同一个子网上有一个 SQL Server (2005) 盒子，我从这个盒子连接到它；它也是 64 位 Windows Server 2003。

这是一个可行的策略吗？考虑到我的架构，有没有更好的方法来解决这个问题？

目前的一个大问题是 ASP 应用程序使用了数百个存储过程；我继承了它，开发是在重叠的部分中完成的，例如，针对用户的简单操作可能会在不同页面上使用不同的过程来完成。一个重要目标是集中对组件的数据访问并抽象出数据库中的实现。因此，如果我添加或更改一个字段，ASP 应用程序将不必知道它的名称；它只会通过对象上的相同属性进行访问。

【问题讨论】：

如果您使用创建 C# 程序集，那么您将不会使用互操作来使用它们。你为什么不继续使用你的存储过程？
@Ramhound：是的。这些程序集将公开一个 COM 接口并以这种方式访问。我们曾经在办公室里称这种反向互操作，但不知道这是否是官方术语。
如果我在经典 ASP 页面中使用 C# 程序集，我假设我必须创建 COM 包装器，否则我无法访问 .NET 托管 dll？请参阅我的编辑以了解我在说什么。
PS - 我将继续调用存储过程（参见上面的编辑），但将从 C# 组件而不是从 ASP 经典页面进行数据访问。

标签： c# asp.net asp-classic windows-server-2003

【解决方案1】：

我采用了非常相似的方法，将一个非常大的计费应用程序从 VB6 迁移到 C#。这是一个完全可行和合理的方法。

我首先会专注于将业务逻辑和数据访问从 UI 迁移到适当的类中，然后开始将 UI 的某些部分从经典 ASP 迁移到 ASP.Net。

在一两个小时内有 200 人，您不会注意到互操作开销。

特别是考虑到您必须处理使用多个代码变体直接访问数据库的 UI，可能值得花一些时间为现有代码进行自动化测试。确保为您编写的新代码遵循测试驱动的方法。如果您没有在自动化测试上投入大量资金，那么在分阶段重新构建应用程序时，您可能会冒着应用程序以难以检测的方式中断的风险。

【讨论】：