我有一份合同，我必须继续开发过去用 VB5 编程的旧应用程序套件。
我有要修复的错误和要开发的新功能。
所以我有几个选择：
- 继续在 VB5 中编程 (NOOOOOOOOOOOOOOO !!!!)
- 将 VB5 转换为 C#（如何？有可能不发疯吗？）
- 重写整个应用程序套件（非常耗时）
还有其他选择吗？我应该怎么办？
编辑：啊，而且它依赖于我想移至 SQL EXPRESS 的 ACCESS 数据库。因为它是一个疯狂的数据库，由一个 90 年代愚蠢的程序员不合逻辑地创建，哈哈。
谢谢
问问题
336 次
7 回答
3
我每次做出的选择都是重写，或者如果我能找到一个合适的替代品，就买一个。
我尝试过从 VB6 到 VB.NET 的增量升级，但我不喜欢这种方法，因为它留下了我不想使用的 ActiveX 控件。重写更干净。
我认为没有从 VB5 到 C# 的转换器。您也许可以从 VB5 转到 VB.NET，然后转换为 C#，但根据我的经验，与尝试升级和摆弄损坏的代码相比，重新编写所需的时间更少。
于 2011-04-11T13:41:36.927 回答
1
没有可靠的方法来做 2) 所以它是 1) 或 3)。
而且我认为您的客户不想为 3) 付费。但也许你可以在可靠性、支持等方面出售它。
否则你会被困在 1)
于 2011-04-11T13:41:59.247 回答
1
一种方法是在 C# 中策略性地重写代码部分 - 您可以从最可能修复错误的区域开始，创建 C# 程序集以反映功能，然后通过 COM 互操作将这些暴露给 VB5 代码。
对于这种方法，强烈建议使用一套好的单元测试！
我听说Michael Feathers 的《有效地使用遗留代码》是了解如何最好地解决此类问题的最佳书籍。
于 2011-04-11T13:43:05.593 回答
1
答案肯定取决于很多因素。我最近有一个类似的项目（一个 10 年以上的旧 VB6 Windows 应用程序，具有大型意大利面条式代码库），并用“混合”方法解决了这个问题：
- 在 VB6 中修复了错误
- 使用 COM 互操作在 .NET 4 中开发了新功能
我们开发了一些 WPF 对话框并将它们设置为与旧界面一起处理新 UI。
此选项仅在新功能完全独立于主应用程序时才有效，但它的优势在于至少可以利用新技术的生产力并为未来的转换铺平道路。
于 2011-04-11T13:43:25.970 回答
1
我最近完成了一个项目，我们使用Artinsoft 的 VB Upgrade Companion将许多旧版 VB6 应用程序转换为 C# 。
决定哪种方法最好是一个艰难的决定。在很多情况下，转换代码最终会非常痛苦，特别是如果有很多基于两个平台之间显着不同的特性的逻辑（例如单索引数组，或通过 Information.Err 处理错误）对象而不是通过异常）。
另一方面，如果您尝试从头开始编写它，您很可能会意外地更改一些在查看原始 VB5 代码时并不立即明显的细微行为。像这样的事情可能很难追踪。
一个好的折衷方案是使用转换器将代码移植过来，然后将其用作从头开始编写内容的指南，因为希望在某些地方您可以将转换后的代码直接提升到新的代码库中。但与此同时，您可以在其他地方编写更多可维护的代码。
综上所述，如果原始的 VB5 编写良好并且（相对）架构良好，那么我建议不要进行任何形式的升级。与仅处理旧代码相比，您将花费更多时间来尝试匹配旧应用程序的现有行为。
不管你决定做什么，祝你好运——你需要它:)
于 2011-04-11T14:00:07.223 回答
0
也许您应该先转换为 vb.net，然后再转换为 C#？
于 2011-04-11T13:40:17.997 回答
0
如果您只需要修复一个错误，并且它是一个相当简单的错误，并且您预计除此之外不会有更多工作 - 坚持使用 VB5。其他任何事情都会带来更多的工作。
但是，如果这真的是一个你期望在未来大量工作的“实时”产品，我可能会从头开始。我的猜测是，自从编写应用程序以来，你已经学到了很多关于设计和架构的知识——所以你不妨借此机会编写一个更易于维护的应用程序。（您可能还知道原始应用程序中的哪些设计决策最终是错误的。）
于 2011-04-11T13:43:29.743 回答