logo标签列表

将VB6应用程序转换为.NET的策略

.netvb.netvb6-migration
7

逐一将表单转换为.NET，然后通过COM-Interop从VB6应用程序调用这些表单，这是一个好主意吗？

这样做的好处是，在整个过程结束时，您只需将VB6应用程序的“外壳”转换为新的.NET应用程序，而所有表单都已准备好在.NET中使用。

是否有更好的策略？

在VB6中，您是否通过COM公开了任何复杂类型？因为这些类型可能在VB6和.Net之间不兼容。例如，如果您在VB6中使用MSXML，则需要将其替换为.Net中的System.Xml；这仅在您不在COM层中使用MSXML类型时才有效。ADO也是如此。 - Polyfun
我还在仔细研究这段代码，但我猜想不行。我把VB6通过VS2005向导处理了一下，结果出现了几千行无法在.NET中编译的代码，所以那可能不是一个选择。 - Craig Johnston
然而，还有另一项服务可用，可以将VB6代码转换为C#。SELISE Phoenix提供此服务（完全功能的转换代码），并向使用该服务的公司提供转换后的支持。https://phoenix.selise.ch/ - Md Ashaduzzaman
5个回答
3

如果是我，我会直接撕掉创可贴。因为在应用程序中加入一个中间状态 [.NET表单和COM-interop] 只会增加不必要的复杂性而没有任何好处。

但是在迁移过程中，我需要应用程序能够完美地为其用户提供功能。 - Craig Johnston
你在迁移实时系统吗？ - M.A. Hanin
2
部署一个未经测试的新的 .net 应用程序是不可行的。关键错误的风险太大了。改变必须更加渐进。 - Craig Johnston
1
克雷格是对的。微软内部人员发布了一篇文章，介绍了他如何试图帮助一些企业通过“大爆炸”方法迁移到.Net，但许多项目因为任务过于庞大而失败。http://blogs.msdn.com/goto100/archive/2008/11/03/rewrite-vs-migrate-vs-reuse-vs-replace.aspx - MarkJ
3
我们有一个 VB6 应用程序正在迁移到 .NET，我们使用 COM-Interop 策略。所有新功能都可以在 .NET 中实现，只有 GUI 部分保留为 VB；同时，我们可以独立开发新的 GUI。
如果您还不知道，您可以使用 Registration-Free COM Interop 进行 COM 互操作，而不必使用注册表（因为这对我们造成了一些问题）：
有些人建议先移植GUI。为什么你最后才移植GUI？ - Craig Johnston
实际上，这个想法是在第一步只移植一些相对复杂的应用程序部分，并使用移植后的程序逻辑创建一个Silverlight应用程序。VB6应用程序将在一段时间内保留，但所有新开发的部分都可以被SL应用程序使用。 - gammelgul
我读到在vb6中使用.NET组件与无需注册Interop存在问题。您在Vb6和.NET之间的Reg-Free Com Interop方面遇到过任何问题吗？ - Craig Johnston
该应用程序已经在一段时间前发布给我们的客户，到目前为止我还没有遇到任何问题。 - gammelgul
然而，还有另一项服务可用，可以将VB6代码转换为C#。SELISE Phoenix提供此服务（完全功能的转换代码），并向使用该服务的公司提供转换后的支持。https://phoenix.selise.ch/ - Md Ashaduzzaman
3

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

1
Artinsoft现在更名为Mobilize.net。 - R.J. Dunnill
1

你所描述的逐步方法会增加额外的工作量，因为你将尝试让VB6和.Net代码共存，除了最简单的应用程序之外，这种方法充满了问题。在未来的某个时候，你可能会遇到一个致命的问题。

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

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

+1 如果您有实际经验。虽然我可以想象“将发生的任何VB6更改应用于.Net代码”可能在某些项目上很耗时。 - MarkJ
0

你会一次只处理一个表格，使用你的系统并发地使用一个或两个数据模型进行大规模复杂数据转换吗？显然这样做会带来麻烦和复杂性。对于大规模数据转换的最佳实践是以最短的停机时间将整个数据模型带到所需的最终状态。同样的道理也适用于大规模代码转换。分阶段地进行长期转换只会增加劳动成本和技术风险。

在我看来，更好的方法是制定.NET代码的最终开发和架构标准，然后投资于一个过程，帮助您以符合这些标准并准确保留遗留业务规则和功能行为的方式高效地重写系统。长期过渡和复杂的混合/中间解决方案最多只是权宜之计，最坏的情况下会导致业务问题和项目失败--应该避免。更好的方法将使您能够将遗留软件以内部一致、独立和良好形式的部分交付到新平台上。此外，以较少、较大的部分交付迁移将比许多小部分更有效率，更少干扰。

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

免责声明：我为Great Migrations工作。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接