耗时更少：将应用程序从 VB5 重写或转换为 C#
我有一份合同，其中我必须继续开发以前用 VB5 编程的旧应用程序套件。
我有错误需要修复，新功能需要开发。
所以我有几个选择：
- 继续使用 VB5 编程 （NOOOOOOOOOOOOOOO！！！）
- 将 VB5 转换为 C#（如何？？？是吗？ 可能不会发疯？）
- 重写整个应用程序套件 （很费时间）
还有其他选择吗？我应该怎么办？
编辑：啊，而且，它依赖于 ACCESS 数据库，我想将其转移到 SQL EXPRESS。因为它是一个由 90 年代的愚蠢程序员不合逻辑地创建的疯狂数据库，哈哈。
谢谢
I've got a contract where I have to continue the development of and old application suite that was programmed in VB5 back in the days.
I've bug to fix and new feature to develop.
So I have a few choices:
- Keep programming in VB5
(NOOOOOOOOOOOOOOO!!!!) - Convert VB5 to C# (How??? Is it
possible without going insane?) - Rewrite the whole application suite
(Very time consuming)
Is there any other choices? What should I do?
EDIT: Ah and also, it relies on an ACCESS database which I'd like to move to SQL EXPRESS. Because it's a crazy database made illogically by a stupid programmer from the '90s lol.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我每次做出的选择就是重写，或者购买合适的替代品（如果我能找到的话）。
我尝试过从 VB6 增量升级到 VB.NET，但我不喜欢这种方法，因为它留下了我不想使用的 ActiveX 控件。重写更干净。
我认为没有从 VB5 到 C# 的转换器。您也许可以从 VB5 转到 VB.NET，然后转换为 C#，但根据我的经验，重写比尝试升级和摆弄损坏的代码更省时。
The choice I've made every time is to just re-write, or purchase a suitable replacement if I could find one.
I have tried doing incremental upgrades from VB6 to VB.NET, but I don't like that approach because it leaves around ActiveX controls that I'd rather not use. Re-writing is cleaner.
I don't think there is a converter from VB5 to C#. You might be able to go from VB5 to VB.NET and then convert to C#, but in my experience it's less time-consuming to re-write than it is to try to upgrade and fiddle around with the broken code.
没有可靠的方法可以做到 2)，所以是 1) 或 3)。
我认为您的客户不想支付 3) 的费用。但也许你可以以可靠性、支持等为卖点。
否则你就会陷入困境 1)
There is no reliable way to do 2) so it's 1) or 3).
And I don't think your customer wants to pay for 3). But maybe you can sell it on reliability, support etc.
Otherwise you're stuck with 1)
一种方法是有策略地用 C# 重写代码部分 - 您可以从最可能修复错误的区域开始，创建 C# 程序集来镜像功能，然后通过 COM 互操作将它们公开给 VB5 代码。
对于这种方法，强烈推荐一套好的单元测试！
我听说有效地使用旧代码 是了解如何最好地解决此类问题的最佳书籍。
One approach would be to tactically rewrite sections of the code in C# - you could start with the areas you are likely to be bugfixing the most, create C# assemblies to mirror the functionality, and then expose these to the VB5 code through COM interop.
A good suite of Unit Tests would be highly recommended for this approach!
I've heard that Working Effectively With Legacy Code by Michael Feathers is the best book around for understanding how best to chop up a problem like this.
答案肯定取决于很多因素。我最近有一个类似的项目（一个 10 多年前的 VB6 Windows 应用程序，具有庞大的意大利面条代码库），并使用“混合”方法解决了这个问题：
我们开发了一些 WPF 对话框，并将它们设计为与旧界面配合以处理新 UI。
此选项仅在新功能相当独立于主应用程序时才有效，但它的优点是至少可以利用新技术的生产力，并为未来的转换铺平道路。
The answer definitely depends on a lot of factors. I recently had a similar project (a 10-year plus old VB6 Windows app with a large, spaghetti codebase), and addressed it with a "hybrid" approach:
We developed some WPF dialogs and styled them to go with the old interface to handle new UI.
This option only works when the new features are fairly independent of the main app, but it has the advantage of at least taking advantage of the productivity of new technologies and also paving the way for future conversion.
我最近完成了一个项目，我们使用 Artinsoft 的 VB Upgrade Companion 将许多旧版 VB6 应用程序转换为 C# 。
决定哪种方法最好是一个艰难的决定。在很多情况下，转换代码最终可能会非常痛苦，特别是如果存在大量基于两个平台之间显着不同的功能的逻辑（例如，单索引数组，或通过 Information.Err 处理错误）对象而不是通过异常）。
另一方面，如果您尝试从头开始编写它，则很可能会意外地更改一些微妙的行为，而这些行为在查看原始 VB5 代码时并不立即明显。像这样的事情可能很难追踪。
一个好的折衷方案是使用转换器来移植代码，然后使用它作为从头开始编写内容的指南，因为希望在某些地方您可以将转换后的代码直接提升到新的代码库中。但与此同时，您可以从在其他地方编写更易于维护的代码中受益。
话虽如此，如果原始 VB5 编写良好并且（相对）架构良好，那么我会建议不要进行任何形式的升级。与仅处理旧代码相比，您将花费更多的时间来尝试匹配旧应用程序的现有行为。
无论你决定做什么，祝你好运 - 你会需要它:)
I've recently finished working on a project where we converted a lot of legacy VB6 applications to C# using Artinsoft's VB Upgrade Companion.
It's a tough call to decide which approach is the best. In a lot of cases, converting the code can end up being very painful, especially if there is a lot of logic based around features which are significantly different between the two platforms (e.g. one-indexed arrays, or handling errors via the Information.Err object instead of through exceptions).
On the other hand, if you try to write it from scratch, there is a good chance that you'll accidentally change some subtle behaviour that isn't immediately obvious when reviewing the original VB5 code. Things like this can be difficult to track down.
A good compromise is to use a converter to port the code over, then use this as a guide for writing things from scratch, as there will hopefully be places where you can just lift converted code across straight into the new code base. At the same time though, you get the benefit of writing more maintainable code everywhere else.
With all that said, if the original VB5 is well written and (relatively) well architected, then I would recommend against any sort of upgrade. You will spend far more time trying to match the existing behaviour of the old application than you would just working on the old code.
Good luck with whatever you decide to do - you'll need it :)
也许您应该首先转换为 vb.net，然后再转换为 C#？
Maybe you should first convert to vb.net, and then to C#?
如果您只是需要修复一个错误，并且这是一个相当简单的错误，并且您预计除此之外不会做更多工作 - 坚持使用 VB5。其他任何事情都会带来更多的工作。
但是，如果这确实是一个“实时”产品，并且您希望在未来进行大量工作，那么我可能会从头开始。我的猜测是，自从编写应用程序以来，您已经学到了很多有关设计和架构的知识 - 因此您不妨借此机会编写一个更易于维护的应用程序。 （您可能还会了解到原始应用程序中的哪些设计决策最终是错误的。）
If you just need to fix a bug, and it's a reasonably simple bug, and you don't anticipate much more work beyond that - stick with VB5. Anything else will introduce far more work.
However, if this is really a "live" product which you expect to work on a lot in the future, I would probably start from scratch. My guess is that you've learned a lot about design and architecture since writing the app - so you might as well take the opportunity to write a more maintainable app. (You'll also probably have learned which design decisions in the original app ended up being mistakes.)