4

我知道有人问了很多关于 VB6 迁移的问题，但我不相信我的确切情况已经在其中得到了回答。

基本上，我们公司希望迁移我们的任务关键型 VB6 业务线应用程序，该应用程序非常大，使用自定义库与其他内部程序和一些我们无权访问源代码的 dll 进行通信。这个遗留应用程序没有任何形式的“最佳实践”。实际上，几乎所有变量都是全局变量，并且大多数代码（例如打印等）只是复制/粘贴到需要的位置。好吧，复制，粘贴和更改只是一点点......

VB.NET 和 C#.NET 之间的决定取决于我们是否应该尝试迁移，并且他们希望我们满足将应用程序转换为基于 Web 的格式的可能性。管理层不会在外部移民公司上花钱。

另一个选项来自我们的基础架构团队，该团队一直在研究使用虚拟化来保留 Visual Basic 6.0 客户端-服务器应用程序

我们的老板希望我们提供高水平的估计和建议，但告诉我们高管们希望在 2010 年 4 月之前完成。

是的，我们笑了。

我的问题是：

有没有人有任何经验可以分享虚拟化路径，因为从开发团队的角度来看，这是一个更可取的选择？它对你有用吗？有没有你会警告的陷阱？

尽管之前的系统分析师给出了 1-2 年的估计，但管理层不断推动 2-4 个月的时间框架。有什么建议可以说服他们这是疯狂的吗？

有没有人成功地将大型 VB6 应用程序迁移到 Web 应用程序？之前的一个VB6 迁移问题的答案是将部分转换为 .NET 启用的 COM 库以掏空 VB6 应用程序。可以使用这种方法吗？这里有人试过成功吗？

4

4 回答 4

5

说服他们疯狂的一条建议是将任务分解为小单元，尽可能多地给出估计并将其提交给管理层。管理层经常无法给出现实估计的原因是他们不了解手头任务的范围。因此，如果您对任务进行切片并让他们了解需要哪些实际工作，那么说服他们会更容易——或者重新考虑选择任务的子集并发布一系列版本。

关于将其“移植”到 .net，一种方法是将 vb6 程序重写为模块 (COM) 并将功能合并到新的 .net 应用程序中，然后一点一点地将模块一个接一个地重写为您喜欢的.网络语言。尽管听起来这可能与任何其他方法一样混乱。

于 2009-11-09T04:13:58.340 回答
4

几个月前我也有同样的情况；最终，我整理了一份演示文稿，概述：

  • 如果我们保留 VB6 版本并尝试维护它，最终会发生什么
  • 如果我们进行部分迁移到 .NET，将会导致地狱（以及浪费的时间）
  • 我们将整个应用程序（以及它使用的所有东西）移植到 .NET 并废弃遗留代码库会快​​多少？

此外，为了帮助您，我向高管们解释了为什么他们的 4 个月时间框架不会飞快：

我们在内部使用这个产品已经六年多了；从一开始，它就被定期修改、添加或以其他方式工作。是什么让您认为我们可以在达到现在所用时间的十五分之一内重写整个解决方案？

有效！

于 2009-11-09T04:13:11.213 回答
3

我们仍然有一些用 VB6 编写的软件作为产品/维护，但 3/4 年前我们选择转向 C#。那是因为 VB6 有很多限制，至少在您开始使用本机 Win32 API 之前（但这与使用 C++ 并没有太大区别）。
.Net 提供了一个非常好的打包框架，使用非常好的工具并将您推向强有序的方向（类型安全、强类型、代码分析、可扩展等）。
我们之所以选择 C# 而不是 VB.Net，是因为语法类似于 C++、Java、Javascript（类 C），但这只是我们的观点。
对我来说，将一个应用程序从 VB6 转换为 web，就像从自行车转换为蔬菜汤……是的！无法比较它们……完全不同的框架，完全不同的开发等等。
我们有一些基于网络的“heavy-activex”解决方案的间接经验，但有一个噩梦......绝对不建议，同样从经济角度来看：也许你可以在合理的时间内有一些“站立”的东西，但你应该采取它就像比萨斜塔（每天都可能倒塌）。

于 2009-11-09T05:29:44.350 回答
2

微软公司刚刚发布了一个基于成功的 VB6 迁移项目的全球案例研究：

http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?casestudyid=4000006181

于 2009-12-16T15:54:15.470 回答