从 VB6 迁移到 .NET/.NET Core 的最佳策略或工具
我的公司有大量用 VB6 编写的遗留应用程序。
我们正处于从 VB6 应用程序迁移到 .NET（特别是 3.5）的过渡过程中。
从 VB6 迁移到 .NET 的最佳策略是什么？
注意：以下更新应转到“项目管理”，与主要问题无关。
[更新]：感谢您迄今为止的反馈
现在有 弹出的更多问题是
- 您将如何分配开发人员开发新应用程序？
- 是否应该有一个特殊的一次性升级部门来转换 旧应用程序到新应用程序？ 或者应该 每个开发者都参与 转换过程？
- 只有高级开发人员才能参与转换吗？ 初级 开发商？ 还是混合的？
看来，我想得越多了 这个问题，更多问题只是显示 向上。
My company has tons of legacy applications that are written in VB6.
We are in transitions from moving VB6 applications to .NET (3.5 specifically).
What would be the best strategy for moving form VB6 to .NET?
NOTE: Below update should go to "Project Management" and has nothing to do with the main question.
[UPDATE]: Thank you for your feedback so far
Now there are
more question that pop up are
- how would you assign developers to develop new applications?
- Should there be a special one-time upgrade division that will convert
legacy apps to new ones? Or should
every developer participate on
conversion process?- Should only senior developers participate on conversion? Junior
developers? or mixed?It seems like, the more I think about
this problem, more questions just show
up.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
显然，这是一项重大任务，需要大量工作。
所以我的建议是将其视为一个非常长期的项目。
心中有一个明确的目标，解决安全性、弹性、可维护性和应用程序的未来等主要问题。
一旦利益相关者同意，开发一个原型系统来测试您的假设，您可以在其中尝试 C# 与 VB.net 或 MVC 与 Webforms。
我会指派你们最好的开发人员来做这件事。
然后从一个小型遗留系统开始，构建您将在其他领域重复使用的核心组件。
在此阶段，从更高级的开发人员开始，但每个人都必须参与并熟悉新框架。
这将确保每个人同时接受培训，没有人掉队。
根据您拥有的应用程序数量，我将轮换开发人员，以便所有系统都能受益。
此外，所有新工作都必须使用您的 .net 语言而不是 VB6 完成。
逐步转换您的每一个旧应用程序。
（只有当它们发生变化或者更新它们有明显的好处时，我才会转换它们。）
这应该为您提供一个坚实的框架供您继续使用，同时仍然确保用户功能不会因您的迁移而受到阻碍。
例如：
我曾在一家拥有大约 40 个左右 VB 应用程序的公司工作。
随着时间的推移，我们已将所有这些都迁移到 C#，现在（5 年后），我们拥有大约 150 个 C# 应用程序（全部位于 .net 2 中）。
这些都共享一个通用框架，使它们易于维护并在必要时进行扩展。
Clearly this is a major undertaking which will involve lots of work.
So my advice would be to treat it like a very long term project.
Have a clear goal in mind, which addresses major issues like security, resilience, maintainability and the future of your applications.
Once this has been agreed on by the stake holders, develop a prototype system to test your assumptions with, where you can try out C# vs VB.net or MVC vs Webforms.
I would assign your best developers for this.
Then start with one your small legacy systems, and build the core components which you will re-use in other areas.
At this stage, start with your more senior developers, but everyone must get involved and be familiar with the new framework.
This will ensure everyone is trained at the same time, and no one is left behind.
Depending on how many applications you have I would rotate developers, so all systems can benefit.
Also all new work must be done in your .net language not in VB6.
Gradually convert each one of your legacy applications.
(I would only convert them if they are changing or if there is a clear benefit to updating them.)
This should give you a solid framework to use going forward, while still ensuring users functionality isn't hindered by your migration.
For example:
I've worked at a company which had roughly 40 or so VB applications.
Over time we have migrated all of these to C# and now (5 years later), we have roughly 150 c# applications (all in .net 2.).
These all share a common framework, making them easy to maintain, and extend where necessary.
尝试使用支持 COM 的 .NET 库替换核心功能。 通过将功能一点点转移到 .NET，“掏空”现有的 VB6 应用程序。
当心完全重写。 尽管它们很诱人，“因为它是干净的切割”——通常疯狂就在前方！ 阅读 Michael Feathers 的《有效处理遗留代码》作为准备。 尽管这本书没有具体讨论“从一种语言迁移到另一种语言”，但它确实展示了您将遇到的许多现实世界的陷阱。
我确实认为所有开发人员都应该定义他们对之前开发的遗留应用程序进行迁移工作的时间段。 由于他们已经拥有领域知识并了解问题空间，因此他们应该是最有生产力的。
Try replacing core functionality with COM enabled .NET libraries. "Hollow out" your existing VB6 apps by moving functionality to .NET bit by bit.
Beware of complete rewrites. Though they are tempting "because it is a clean cut" - usually madness lays ahead! Read "Working Effectively with Legacy Code" by Michael Feathers as a preparation. Though the book does not specifically go into "moving from one language to another" it does show a lot of real world pitfalls you will encounter.
I do think that all developer should have defined time slots where they do migration work on the legacy apps they developed before. Since they already have domain knowledge and know the problem space they should be the most productive.
以下是我的答案的改编类似的问题。
自动转换大型程序是比重写更好的选择。 一个常见的陷阱是开始乐观地重写一个大型软件，在修复旧架构中的一些众所周知的缺陷方面取得良好的早期进展，然后陷入您一直认为理所当然的功能中年。 此时，您的管理层开始变得焦躁不安，一切都会变得非常不舒服。
...这是 Microsofty 的一篇博客文章 同意我的观点：
这个优秀的 Microsoft 页面 推荐了两个第三方迁移工具比功能不足的内置 VB.NET 升级向导更好 - Artinsoft 和 CodeArchitects VBMigration。 Artinsoft编写了内置的VB.NET升级向导，这是他们的改进版本。 CodeArchitects 由 Francesco Balena 创立，他编写了一些 关于 VB6 和 VB.NET 的经典书籍。
同一个微软页面还说：
编辑：宋在评论中说：“我不太喜欢自动生成代码，因为最初调试起来比较困难，并且可能需要与重写整个代码一样长的时间”。 我必须强烈反对。 一般来说，我也不喜欢代码生成，但在这种情况下，生成的代码的结构将与原始 VB6 相同，并且应该几乎完全可用。 我自己实际上还没有尝试过这些工具，但是从他们的 客户 推荐 这一承诺已兑现。
我根据他们协助许多迁移的经验，重复上面的微软建议 - “完全重写比转换[我的重点]成本更高且更困难”--这与以下假设完全矛盾：可能需要同样的时间。 如果您想改进 VB6 的结构，那么逐步重构可能比重写更具成本效益。
Here is an adaptation of my answer to a similar question.
Converting large programs automatically is a better choice than rewriting. It's a common pitfall to start out optimistically rewriting a large piece of software, make good early progress fixing some of the well-known flaws in the old architecture, and then get bogged down in the functionality that you've just been taking for granted for years. At this point your management begin to get twitchy and everything can get very uncomfortable.
...and here's a blog post by a Microsofty that agrees with me:
This excellent Microsoft page recommends two third party migration tools as better than the underpowered built-in VB.NET upgrade wizard - Artinsoft and CodeArchitects VBMigration. Artinsoft wrote the built in VB.NET upgrade wizard, this is their improved version. And CodeArchitects was founded by Francesco Balena, who wrote some of the classic books on VB6 and VB.NET.
The same Microsoft page also says:
EDIT: Sung says in the comments: "I am not a big fan of auto generation of code because it is harder to debug initially and might take just as long as it takes to rewrite whole thing". I have to disagree strongly. In general I too am no fan of code generation, but in this case the resulting code will be structured identically to your original VB6 and should be almost totally functional. I haven't actually tried these tools myself yet, but from their customer testimonials this promise is fulfilled.
And I repeat the Microsoft advice just above, based on their experience of assisting many migrations - "a complete rewrite is far more costly and difficult than converting [my emphasis]" - a flat contradiction of the supposition that it might take the same time. If you want to improve the structure of the VB6, migration then gradual refactoring is likely to be far more cost effective than a rewrite.
请参阅此：
https://stackoverflow.com/ questions/507291/should-we-select-vb-net-or-c-when-upgrading-our-legacy-apps
当然，C# 与 VB.Net 只是其中的一部分。
例如，要考虑的另一件事是您是否想利用此机会将这些应用程序移动到 Intranet（如果您还没有这样做）。 或者你想深入研究微软的堆栈多深。 例如，Winforms 是否足够，或者您想使用 WPF。
See this:
https://stackoverflow.com/questions/507291/should-we-select-vb-net-or-c-when-upgrading-our-legacy-apps
Of course, C# vs VB.Net is just one part of it.
For example, another thing to consider are if you want to use this opportunity to move these apps to an intranet, if you haven't already. Or how deep do you want to delve into microsoft's stack. Is Winforms enough or do you want to use WPF, for example.
我将从微软的工具开始：
http://msdn.microsoft.com/en -us/library/aa480541.aspx
I would start with Microsoft's tools:
http://msdn.microsoft.com/en-us/library/aa480541.aspx