将大型 VB6 应用程序升级到 .NET。 对VB迁移合作伙伴的看法
我有一个非常大的 VB6 代码库，其中包含大量第 3 方控件。 想要将其移至.NET。 重写它是毫无疑问的——客户认为花钱获得同样的东西没有任何价值。 使用内置升级向导迁移到 .NET 基本上是不可能的。
有没有人尝试过 http://www.vbmigration.com/ 的 VB 迁移合作伙伴 如果有的话，经历是什么样的？
I have a really large VB6 code base with a ton of 3rd party controls. Want to move it to .NET. Rewriting it is out of question - the client sees no value in spending money to get the same thing. Moving to .NET with the built-in upgrade wizard is basically a non-starter.
Has anyone tried the VB Migration Partner from http://www.vbmigration.com/
If so, what have been the experiences like?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我是 VB 迁移合作伙伴工具（位于 www.vbmigration.com）的主要作者。 一般来说，我们会很快回复现有或潜在客户的所有请求。 如果发现很难联系我们，我们深表歉意。 请访问http://www.vbmigration.com/contactus.aspx重试
我们确实相信我们的工具能够处理非常大的 VB6 应用程序。 实际上，我们的大多数客户都使用它来迁移 200-500K 行代码范围内的应用程序。 我们目前正在开发一个“怪物应用程序”，它包含超过 1300 万个 LOC，分布在 1200 多个项目中。
正如 RSConley 所建议的，如果您的应用程序可以部分迁移和测试，那么任何转换工具都效果最佳。 我们支持 VB6 项目组（在单个操作中转换）、批量转换，并且支持与源代码控制工具的集成。 （例如，我们保留上一代的解决方案/项目指南，以便您的 SC 工具知道如何处理新生成的代码。）
最后，我们即将发布版本 1.11，它可以生成与二进制兼容的 .NET DLL 。原始 COM DLL，以便您可以从应用程序所有其他部分使用的最基本组件开始一次迁移一个组件，而无需重新编译它们。 （据我们所知，VB Migration Partner 是唯一具有此功能的工具。）
Francesco Balena - VB Migration Partner 团队
I am the lead author of the VB Migration Partner tool (featured at www.vbmigration.com). In general we answer very quickly to all requests coming from existing or potential customers. I am sorry if found it difficult to contact us. Please try again at http://www.vbmigration.com/contactus.aspx
We do believe that our tool is capable to tackle very large VB6 applications. Actually, most of our customers are using it to migrate applications in the range 200-500K lines of code. We are currently working on a "monster app" of over 13 millions LOCs partitioned in 1200+ projects.
As RSConley suggests, any conversion tool works best if your application can be migrated and tested in parts. We support VB6 project groups (that are converted in a single operation), batch conversions, and we support integration with source code control tools. (For example, we preserve solution/project guids from previous generation, so that your SC tool knows how to deal the newly generated code.)
Finally, we are about to release version 1.11, which can generate .NET DLLs that are binary compatible with the original COM DLLs, so that you can migrate one component at the time starting with the most basic ones that are used by all others portions of your app, without having to re-compile them. (As far as we know, VB Migration Partner is the only tool with this feature.)
Francesco Balena -- VB Migration Partner Team
我以前从未与 VB 迁移人员合作过，但我强烈建议不要将代码库迁移到 .NET。 它确实没有增加价值。
我所取得的巨大成功是在 .NET 中添加新功能，并通过 VB6 应用程序中的 COM 互操作来获取它。 这是非常轻松的，并且是在遗留应用程序中利用 .NET 的好方法。
...我的 2 美分
I've never worked with the VB migration guys before, however I would highly recommend against migrating the code base to .NET. It really doesn't add value.
What I've had great success doing is adding new functionality in .NET and getting at it via COM interop from the VB6 application. This is pretty effortless and is a good way of utilizing .NET in legacy applications.
...my 2 cents
简而言之，VB6 和 VB.NET（以及 C#）是独立但相关的语言。 两个平台之间存在许多细微的差别（Integer 是 Int32，而不是 Int16）和明显的差别（图形、表单和打印引擎）。 您需要将其视为正在转换到完全不同的平台。
我发现除了某些特定情况之外，各种迁移工具都不值得付出努力。 例如使用水晶报表的数据库前端。
至于移民的价值。 只有您和您的公司才能做出决定。 在 PC 上维护一个应用程序足够长的时间，最终您必须认真考虑它。 主要是为了利用全新的技术（例如从 DOS 到 Windows 的切换）。 我的应用程序始于 1985 年，在 20 年的历史中发生了 3 次重大转换（工作站到 DOS、DOS 到 Windows 3.X、Windows 3.X 到 32 位 Windows 和面向对象框架）。
我们出于多种原因考虑使用 .NET。 VB.NET 是一种相关语言，泛型和继承允许我们将大部分样板代码压缩为几行。 更丰富的图形API等等。 当然，还有一个令人头疼的问题，那就是转换与一切的权衡。 然而，当我们切换到面向对象的框架时，我们的应用程序变成了一个通过 COM 链接到多个 DLL 的小型 EXE。 由于我们的应用程序结构，我们可以进行零碎的转换和测试。
如果您打算进行转换，我强烈建议您将 VB6 中的应用程序重构为可以部分转换和测试的结构。 您将能够使用 Active DLL 来完成此任务。 如果您尝试一次性完成此任务，那么您会发现项目的 80% 会很快完成，而最后 20% 将是纯粹的地狱。 通过逐步转换，您将在每一步都留下可用的软件。
这里更全面地探讨了这些问题
如何切换从 VB6 到 VB.NET 的大型应用程序
The short answer is that VB6 and VB.NET (and consequently C#) are separate but related languages. There are many subtle (Integer being Int32 instead of Int16) and gross differences (graphics, form, and printing engines) between the two platforms. You need to treat this as if you are converting to a completely different platform.
I have found various migration tools not to be worth the effort except for some specific circumstances. For example a database front end using crystal reports.
As for the worth of migration. Only you and your company can make that decisions. Maintain a application long enough on a PC eventually you have to seriously consider it. Mostly to take advantage of a totally new technology (the switch from DOS to Windows for example). My applications was started in 1985 and there has been three major conversion in it's 20 years history (Workstation to DOS, DOS to Windows 3.X, Windows 3.X to 32-bit Windows and object oriented framework).
And We are considering .NET for several reasons. VB.NET is a related language, Generics and Inheritance allow much of our boilerplate code to compressed into a few lines. A richer Graphics API, and so on. Of course there is the total headache of the conversion weighing against everything. However when we switched to a object oriented framework our application became a small EXE linked through COM to several DLLs. We have the luxury of converting and testing piecemeal because of our application structure.
I strong recommend that if you intend to convert that you refactor your application in VB6 to a structure that can be converted and tested in parts. You will be able to use Active DLLs to accomplish this. If you try to do this in one go then you will find that 80% of the project will go quickly and the last 20% will be pure hell. By converting piecemeal you will be left with working software at every step.
The issues is explored more fully here
How to Switch a Large App from VB6 to VB.NET