我知道有很多关于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应用程序成功的网络应用程序?之前的VB6 migration questions之一得到了将部分转换为支持.NET的COM库以掏空VB6应用程序的答案。可以使用这种方法吗?有没有人在这里成功尝试过?
答案 0 :(得分:5)
关于将它“移植”到.net,一种方法是将vb6程序重写为模块(COM)并将功能合并到一个新的.net应用程序中,然后在模块之后逐个重写模块你最喜欢的.net语言。尽管如此,这可能与其他方法一样混乱。
答案 1 :(得分:4)
另外,只是为了帮助你,这就是我向高管们解释为什么他们4个月的时间框架无法飞行的原因:
我们已经在内部使用该产品超过六年;从一开始,它就被定期修改,添加或以其他方式工作。是什么让你认为我们可以在我们现在所处的时间的十五分之一内重写整个解决方案?
有效!
答案 2 :(得分:3)
我们仍然使用VB6编写了一些产品/ mainteinance软件,但是3/4年前我们选择转向C#。那是因为VB6有很多限制,至少在你开始使用本机Win32 API之前(但这与使用C ++没有什么不同)。
.Net提供了一个非常好的打包框架,使用非常好的工具并将您推向强有序的方向(类型安全,强类型,代码分析,可扩展等)。
我们在VB.Net上选择了C#,因为语法类似于C ++,Java,Javascript(类C),但它只是我们的观点。
至于我,将应用程序从VB6转为网络,就像是从自行车切换到蔬菜汤......是的!无法比较它们......完全不同的框架,完全不同的发展等。
我们有一些基于网络的“重度主动”解决方案的间接经验,但是有一个噩梦...绝对未经批准,也来自经济观点:也许你想在合理的时间内“站立”,但你应该采取它像比萨斜塔(每天可能崩溃)。
答案 3 :(得分:2)
微软公司刚刚发布了一个基于成功的VB6迁移项目的全球案例研究:
http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?casestudyid=4000006181