从 VB6 迁移到 .NET/.NET Core 的最佳策略或工具 [关闭]答案

【问题标题】：Best Strategy or tools for migrating from VB6 to .NET/.NET Core [closed]从 VB6 迁移到 .NET/.NET Core 的最佳策略或工具 [关闭]
【发布时间】：2010-10-15 14:19:50
【问题描述】：

我的公司有大量用 VB6 编写的遗留应用程序。

我们正在从 VB6 应用程序迁移到 .NET（特别是 3.5）。

将 VB6 迁移到 .NET 的最佳策略是什么？

注意：以下更新应转到“项目管理”，与主要问题无关。

[更新]：感谢您迄今为止的反馈
现在有弹出的更多问题是

您将如何分配开发人员开发新应用程序？

是否应该有一个特殊的一次性升级师会转换旧应用到新应用？或者应该每个开发者都参与转换过程？

是否应该只有高级开发人员才能参与转换？初级开发商？还是混合的？

似乎，我想得越多这个问题，更多的问题只是显示起来。

【问题讨论】：

您是否看到其他有关 VB6 迁移的问题？我认为应该有一个 vb6-migration 标签。我现在要发明它并取下你的“过渡”标签，恕我直言，这似乎有太多的含义。
@MarkJ：谢谢。它看起来更具描述性
@Sung：没问题。我认为它更具描述性，它将所有 VB 迁移问题联系在一起。我进行了一些搜索并标记了所有似乎相关的问题。
搜索很有趣——我错过了其他一些问题。当我有机会时，我会用我对这个问题的惯常喋喋不休的方式给他们一些答案。
然而，还有另一项可用的服务将 VB6 代码转换为 C#。 SELISE Phoenix 为使用它的公司提供服务（功能齐全的转换代码）和转换后支持。 phoenix.selise.ch

标签： .net vb6 legacy vb6-migration

【解决方案1】：

显然，这是一项涉及大量工作的重大任务。
所以我的建议是把它当作一个非常长期的项目来对待。

心中有一个明确的目标，它可以解决安全性、弹性、可维护性和应用程序的未来等主要问题。

一旦利益相关者同意这一点，请开发一个原型系统来测试您的假设，您可以在其中尝试 C# 与 VB.net 或 MVC 与 Webforms。我会为此分配您最好的开发人员。

然后从您的小型遗留系统开始，构建您将在其他领域重复使用的核心组件。
在这个阶段，从你更资深的开发人员开始，但每个人都必须参与并熟悉新框架。
这将确保每个人都同时接受培训，并且没有人掉队。
根据您拥有的应用程序数量，我会轮换开发人员，这样所有系统都可以受益。

此外，所有新工作都必须使用您的 .net 语言而不是 VB6 来完成。

逐步转换您的每个旧应用程序。（我只会在它们发生变化或更新它们有明显好处的情况下转换它们。）

这应该为您提供一个可靠的框架以供您继续使用，同时仍确保用户功能不会受到您的迁移的阻碍。

例如：
我曾在一家拥有大约 40 个左右 VB 应用程序的公司工作。
随着时间的推移，我们已经将所有这些迁移到 C#，现在（5 年后），我们有大约 150 个 c# 应用程序（全部在 .net 2 中）。

这些都共享一个通用框架，使它们易于维护，并在必要时扩展。

【讨论】：

现在，这个“例如”段落给我带来了另一个问题（问题已更新）
已更新。您可能希望将这些拆分为子问题。尽管这些正在远离开发，转向项目管理。
@Bravax：你完全正确。我应该让开发远离项目管理。
+1 根据实际经验回答！我很好奇。您是否使用 Artinsoft 之类的工具重写或自动迁移应用程序？如果是重写，您是否考虑过使用这些工具？在您看来，利弊是什么？
我们重写了它们。优点是与新框架完全集成，这使得现在的维护变得更加容易。缺点是花费的时间长，但老实说，我们一点也不着急，我们的用户也没有注意到这次升级。（除了他们获得的新功能。）

【解决方案2】：

这是我的answer 对类似问题的改编。

自动转换大型程序比重写更好。开始乐观地重写一大块软件，在修复旧架构中的一些众所周知的缺陷时取得良好的早期进展，然后陷入你刚刚认为理所当然的功能，这是一个常见的陷阱年。在这一点上，你的管理开始变得紧张，一切都会变得非常不舒服。

...这里是一个 Microsofty 的博客文章 agrees with me:

我在 .NET 早期工作过的许多公司首先考虑重写，部分原因是在迁移到 .NET 的同时，他们强烈希望改进底层架构和代码结构。不幸的是，其中许多项目遇到了困难，有几个项目从未完成。他们试图解决的问题太大了

这个优秀的 Microsoft page 推荐两个第三方迁移工具，比功能不足的内置 VB.NET 升级向导更好 - Artinsoft 和 CodeArchitects VBMigration。 Artinsoft 编写了内置的 VB.NET 升级向导，这是他们的改进版本。 CodeArchitects 是由 Francesco Balena 创立的，他在 VB6 和 VB.NET 上编写了一些 classic books。

同样的微软页面还说：

对 .NET 进行完全重写要比转换成本高得多，而且很难做好 [比转换] ...我们只在少数情况下推荐这种方法。

编辑：Sung 在 cmets 中说：“我不是自动生成代码的忠实拥护者，因为它最初很难调试，并且可能需要与重写整个代码一样长的时间”。我不得不强烈反对。一般来说，我也不喜欢代码生成，但在这种情况下，生成的代码的结构将与您原来的 VB6 相同，并且应该几乎完全可以使用。我自己还没有真正尝试过这些工具，但是从他们的customer testimonials 这个承诺已经实现。

我重复上面的微软建议，基于他们协助许多迁移的经验 - “与转换 [我的重点] 相比，完全重写成本和困难得多” - 与假设它可能需要相同的时间。如果要改进 VB6 的结构，迁移然后逐步重构可能比重写更具成本效益。

【讨论】：

我不是自动生成代码的忠实拥护者，因为它最初很难调试，并且可能需要与重写整个代码一样长的时间；我的经验是，调试比编写实际代码要长 1.5~2 倍；我倾向于先编写较小的模块然后继续。
这是对现有代码的自动更改，而不是自动生成代码，我同意这可能会令人讨厌。根据微软对客户体验的总结，这个过程比重写花费的时间要少得多。一个重要的考虑因素：您是否对代码进行了测试。
@Sung 再次。我认为您的反对意见很有趣，其他人可能也有类似的想法，所以我编辑了我的答案以包含一些关于它的内容——事实上，这是一个非常强烈的分歧。希望没关系！

【解决方案3】：

尝试用支持 COM 的 .NET 库替换核心功能。通过将功能一点一点地迁移到 .NET 来“挖空”现有的 VB6 应用程序。

谨防完全重写。尽管它们很诱人，“因为它是干净利落的”——通常疯狂就在前面！阅读 Michael Feathers 的“有效地使用遗留代码”作为准备。虽然这本书并没有专门讨论“从一种语言迁移到另一种语言”，但它确实展示了你会遇到的许多现实世界的陷阱。

我确实认为所有开发人员都应该确定他们对之前开发的旧版应用程序进行迁移工作的时间段。由于他们已经拥有领域知识并且知道问题空间，因此他们应该是最有生产力的。

【讨论】：

我发现这本书非常难读。
Dun3：你建议这个答案是因为你已经这样做了，还是因为它看起来应该有效？我一直在这样做的地方，结果是 COM 互操作（使用 .NET 会变慢）成为限制性能的瓶颈。
@Arafangion - 是的，我已经做到了。不过，我确实同意——人们真的必须了解“切片”的性能影响。但是，与使用 Web 服务相同的规则也适用。避免聊天界面，它应该很少成为问题。

【解决方案4】：

看这个：
https://stackoverflow.com/questions/507291/should-we-select-vb-net-or-c-when-upgrading-our-legacy-apps

当然，C# vs VB.Net 只是其中的一部分。

例如，另一件要考虑的事情是，如果您还没有利用这个机会将这些应用程序移动到 Intranet，那么您是否还没有这样做。或者你想深入研究微软的堆栈。例如，Winforms 够用还是要使用 WPF。

【讨论】：

【解决方案5】：

我会从微软的工具开始：

http://msdn.microsoft.com/en-us/library/aa480541.aspx

【讨论】：

我什至不知道 MSDN 上有这样的指南...
微软工具是可悲的——根据编写它的人的说法。 devx.com/vb/Article/16822 一篇更好的 Microsoft 文章是最近来自 Microsoft UK msdn.microsoft.com/en-gb/dd408373.aspx