将 VB6 应用程序转换为 .NET 的策略
开始将表单一次转换为 .NET，然后通过 COM 互操作从 VB6 应用程序调用，这是一个好主意吗？
这样，在该过程结束时，您只需将 VB6 应用程序的“外壳”转换为新的 .NET 应用程序，并且所有表单都已准备好进入 .NET。
有更好的策略吗？
Would it be a good idea to start converting forms into .NET one at a time which you would then invoke from the VB6 app via COM-interop.
This way, by the end of the process you would just convert the 'shell' of the VB6 application into a new .NET app, and all your forms are ready to go in .NET.
Is there a better strategy?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我们有一个 VB6 应用程序正在移植到 .NET，并且我们使用 COM-Interop 策略。所有新功能都可以在 .NET 中实现，只有 GUI 部分仍然是 VB；同时，我们可以独立开发新的GUI。
如果您还不知道这一点，您可以使用免注册 COM Interop 来执行 COM Interop，而无需使用注册表（因为这给我们带来了一些问题）：
We have a VB6 application which is being ported to .NET either, and we use the COM-Interop strategy. All new features can be implemented in .NET, only the GUI-stuff remains VB; at the same time, we can develop a new GUI independently.
If you don't already know this, you can do COM Interop without using the registry (as this caused some problems for us) with Registration-Free COM Interop:
如果是我，我会直接撕掉创可贴。我认为为应用程序提供中间状态 [.NET Forms 和 COM-interop] 没有任何好处，因为它只会增加不必要的复杂性。
If it were me, I'd just rip the Band-Aid right off. I don’t see any benefit in having an in-between state [.NET Forms and COM-interop] for your application because it just adds unneeded complexity.
关于转换策略有很多建议。
There's lots of advice on strategies for conversion.
您所描述的零碎方法将产生额外的工作，因为您将尝试使 VB6 和 .Net 代码共存，这在除了最简单的应用程序之外的任何应用程序上都充满了问题。在路上的某个地方，您可能会被一个可能会成为阻碍的陷阱绊倒。
我建议采用以下方法（基于成功将 600,000 行 VB6 应用程序迁移到 .Net）：
确保现有的 VB6 代码库经过正确的版本控制和标记。
为 VB6 代码库编写回归测试，最好是自动化的。
采用已知的 VB6 代码标签基线并将其作为单个实体迁移到 .Net。您的客户继续使用 VB6 版本。
对迁移的代码运行回归测试。
当所有测试都通过后，将自采用原始 VB6 基线以来发生的任何 VB6 更改应用于 .Net 代码。
交付到UAT然后上线。
The piecemeal approach you describe will create extra work because you will be trying to get VB6 and .Net code to co-exist, which is fraught with problems on anything but the simplest applications. Somewhere down the road you are likely to trip over a gotcha which may be a showstopper.
I would recommend the following approach (based on successfully migrating a 600,000 line VB6 app to .Net):
Make sure your existing VB6 code base is properly version controlled and labelled.
Write regression tests for your VB6 code base, preferably automated.
Take a known VB6 code label baseline and migrate it as a single entity to .Net. Your customers continue to use the VB6 version.
Run your regression tests on the migrated code.
When all the tests pass, apply to the .Net code any VB6 changes that occurred since you took the original VB6 baseline.
Deliver to UAT and then live.
您是否会一次对一个表进行大型复杂的数据转换，并且您的系统在较长时间内同时使用一种、另一种或两种数据模型？显然，这会带来麻烦和复杂性。大型数据转换的最佳实践是在尽可能短的中断时间内使整个数据模型达到所需的最终状态。同样的推理也适用于大规模代码转换。长期零碎地进行这些工作会增加劳动力成本和技术风险，从而带来麻烦。
IMO，更好的方法是为您的 .NET 代码制定最终状态开发和架构标准，然后投资一个流程，帮助您以符合这些标准的方式有效地重写系统，并准确地保留遗留业务规则和功能行为。漫长的过渡和复杂的混合/中间解决方案最多只是权宜之计，会导致业务问题，最坏的情况会导致项目失败——应该避免它们。更好的方法将使您能够以内部一致、独立且格式良好的方式将遗留软件交付到新平台。此外，以更少、更大的部分来交付迁移将比许多小部分更加高效且破坏性更小。
使这种方法可行的关键是使用下一代 VB6/COM/ASP 到 .NET 工具，这些工具允许您迭代地校准、自定义和验证自动重写过程，从而平衡自动转换与手动工作。 Great Migrations 中的工具是专门为实现此方法而设计的。我们称之为“工具辅助重写”。我们已经在几个大型迁移项目中使用了这种方法，包括将 VB6/COM 的 1.2M LOC 应用程序组合升级到重新设计的 C#/.NET。
免责声明：我为大迁徙工作。
Would you do a large complex data conversion one-table at a time, with your systems using one, the other, or both data models concurently for an extended period? Clearly this is asking for trouble and complexity. Best practice for large data conversions is to do them in a way that brings the entire data model to its desired end state within the shortest possible outage. The same reasoning applies to large-scale code conversions. Doing them piecemeal over and extended period of time is asking for trouble in terms of increases labor costs and technical risk.
IMO, a better approach is to formulate the end-state development and architecture standards for your .NET code and then invest in a process that helps you efficiently rewrite your system in a way that conforms to those standards and accurately preserves legacy business rules and functional behavior. Long transitions and complex hybrid/intermediate solutions are only a stop-gap at best cause business problems and project failure at worst -- they should be avoided. A better approach will allow you to deliver the legacy software to the new platform in internally consistent, independent, and well-formed pieces. Furthermore, delivering the migration in fewer, larger pieces will be more efficient and less disruptive than many little pieces.
The key to making this approach viable is to use next generation VB6/COM/ASP to .NET tools that allow you to iteratively calibrate, customize, and verify an automated rewrite process that balances automated conversion with manual work. The tools from Great Migrations are specifically designed to enable this methodology. We call it the "tool-assisted rewrite". We have used this approach on several large migrations projects including upgrading an application portfolio of 1.2M LOC of VB6/COM to re-engineered C#/.NET.
Disclaimer: I work for Great Migrations.