我有一个非常大的VB6代码库，有大量的第三方控件。想将其移至.NET。重写它是不可能的 - 客户认为没花钱去做同样的事情。使用内置升级向导迁移到.NET基本上是不起作用的。
是否有人从http://www.vbmigration.com/尝试了VB迁移合作伙伴 如果是这样，那经历是什么样的？
答案 0 :(得分：5)
我是VB Migration Partner工具的主要作者（在www.vbmigration.com上发布）。通常，我们会很快回复来自现有或潜在客户的所有请求。如果发现很难联系我们，我很抱歉。请在http://www.vbmigration.com/contactus.aspx
再试一次我们相信我们的工具能够处理非常大的VB6应用程序。实际上，我们的大多数客户都在使用它来迁移200-500K行代码范围内的应用程序。我们目前正在开发一个超过1300万个LOC的“怪物应用程序”，分为1200多个项目。
正如RSConley建议的那样，如果您的应用程序可以部分迁移和测试，那么任何转换工具都能发挥最佳作用。我们支持VB6项目组（在单个操作中转换），批量转换，并且我们支持与源代码控制工具的集成。 （例如，我们保留上一代的解决方案/项目指南，以便您的SC工具知道如何处理新生成的代码。）
最后，我们即将发布版本1.11，它可以生成与原始COM DLL二进制兼容的.NET DLL，这样您就可以在开始使用所有人使用的最基本的组件时迁移一个组件。应用程序的其他部分，无需重新编译它们。 （据我们所知，VB Migration Partner是唯一具有此功能的工具。）
Francesco Balena - VB移民合作伙伴团队
答案 1 :(得分：4)
我之前从未与VB迁移人员合作过，但我强烈建议不要将代码库迁移到.NET。它确实没有增加价值。
我所取得的巨大成功是在.NET中添加新功能，并通过VB6应用程序的COM互操作获取。这非常轻松，是在遗留应用程序中使用.NET的好方法。
......我的2美分
答案 2 :(得分：4)
简短的回答是VB6和VB.NET（以及C＃）是独立但相关的语言。在两个平台之间有许多微妙的（Integer是Int32而不是Int16）和粗略的差异（图形，表格和打印引擎）。您需要将此视为转换为完全不同的平台。
我发现除了某些特定情况外，各种迁移工具都不值得付出努力。例如，使用水晶报告的数据库前端。
至于移民的价值。只有您和您的公司才能做出决定。在PC上维护一个足够长的应用程序，最终你必须认真考虑它。主要是利用一种全新的技术（例如从DOS切换到Windows）。我的应用程序始于1985年，在其20年的历史中已有三次主要的转换（工作站到DOS，DOS到Windows 3.X，Windows 3.X到32位Windows和面向对象的框架）。
我们正在考虑.NET有几个原因。 VB.NET是一种相关语言，Generics和Inheritance允许我们的许多样板代码压缩成几行。更丰富的Graphics API，等等。当然，转换的全部头痛都会影响到一切。然而，当我们切换到面向对象的框架时，我们的应用程序变成了一个通过COM链接到几个DLL的小EXE。由于我们的应用程序结构，我们可以轻松转换和测试零碎。
我强烈建议，如果您打算进行转换，则可以将VB6中的应用程序重构为可以部分转换和测试的结构。您将能够使用Active DLL来完成此任务。如果你试着一次性完成这项任务，那么你会发现80％的项目会很快完成，最后的20％将是纯粹的地狱。通过零碎转换，您将在每一步都留下工作软件。
这里更充分地探讨了这些问题