7

一次开始将表单转换为 .NET 是一个好主意，然后您将通过 COM-interop 从 VB6 应用程序调用它。

这样，在该过程结束时，您只需将 VB6 应用程序的“外壳”转换为新的 .NET 应用程序，您的所有表单都已准备好进入 .NET。

有更好的策略吗？

4

5 回答 5

3

如果是我，我会直接撕掉创可贴。我认为为您的应用程序设置中间状态 [.NET Forms and COM-interop] 没有任何好处，因为它只会增加不必要的复杂性。

于 2010-04-27T11:14:13.337 回答
3

我们也有一个 VB6 应用程序正在移植到 .NET，并且我们使用 COM-Interop 策略。所有新功能都可以在 .NET 中实现，只有 GUI 的东西仍然是 VB；同时，我们可以独立开发新的GUI。

如果您还不知道这一点，您可以在不使用注册表的情况下使用无注册 COM 互操作进行 COM 互操作（因为这给我们带来了一些问题）：

于 2010-04-27T11:29:59.790 回答
3

有很多关于转换策略的建议。

于 2010-04-28T08:42:51.787 回答
1

您描述的零碎方法将产生额外的工作，因为您将尝试使 VB6 和 .Net 代码共存，这在除了最简单的应用程序之外的任何东西上都充满了问题。在路上的某个地方，您可能会绊倒一个陷阱，这可能是一个阻碍。

我会推荐以下方法（基于成功将 600,000 行 VB6 应用程序迁移到 .Net）：

确保您现有的 VB6 代码库得到适当的版本控制和标记。为您的 VB6 代码库编写回归测试，最好是自动化的。采用已知的 VB6 代码标签基线并将其作为单个实体迁移到 .Net。您的客户继续使用 VB6 版本。对迁移的代码运行回归测试。当所有测试都通过后，将自采用原始 VB6 基线以来发生的任何 VB6 更改应用于 .Net 代码。交付给 UAT，然后生活。

于 2010-04-27T16:28:56.167 回答
0

您是否会一次执行一个大型复杂数据转换一个表，而您的系统会在较长时间内同时使用一个、另一个或两个数据模型？显然，这是在自找麻烦和复杂性。大数据转换的最佳实践是在尽可能短的中断时间内使整个数据模型达到其所需的最终状态。同样的推理也适用于大规模的代码转换。在增加劳动力成本和技术风险方面，零敲碎打地做这些是自找麻烦。

IMO，更好的方法是为您的 .NET 代码制定最终状态开发和架构标准，然后投资一个流程，帮助您以符合这些标准的方式有效地重写您的系统并准确地保留遗留的业务规则和功能行为。长时间的过渡和复杂的混合/中间解决方案充其量只是权宜之计，最坏的情况是会导致业务问题和项目失败——应该避免它们。更好的方法将允许您以内部一致、独立和格式良好的部分将旧软件交付到新平台。此外，以更少、更大的部分进行迁移将比许多小部分更有效且破坏性更小。

使这种方法可行的关键是使用下一代 VB6/COM/ASP 到 .NET 工具，这些工具允许您迭代校准、自定义和验证自动重写过程，从而平衡自动转换与手动工作。Great Migrations的工具是专门为实现这种方法而设计的。我们称之为“工具辅助重写”。我们在几个大型迁移项目中使用了这种方法，包括将 1.2M LOC 的 VB6/COM 应用程序组合升级到重新设计的 C#/.NET。

免责声明：我为大迁徙工作。

于 2010-05-02T17:09:07.350 回答