.net - VB6 迁移建议

Question

关闭。这个问题需要更多 focused .它目前不接受答案。












想改进这个问题？更新问题，使其仅关注一个问题 editing this post .

8年前关闭。




Improve this question




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

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

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

另一个选项来自我们的基础架构团队，他们一直在查看 Using Virtualization to Preserve a Visual Basic 6.0 Client-Server Application

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

是的，我们笑了。

我的问题是:

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

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

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

Answer 1

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

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