Dan*_*ath 4 .net virtualization vb6-migration
我知道有很多关于VB6迁移的问题,但我不相信我的确切情况已在其中得到解答.
基本上,我们公司希望迁移我们的任务关键型VB6业务线应用程序,这个应用程序非常庞大,使用自定义库与其他内部程序进行通信,而一些dll则无法访问源代码.这个遗留应用程序没有任何类似的"最佳实践".事实上,几乎所有变量都是全局变量,大多数代码(如打印等)都只是复制/粘贴到需要的地方.好吧,复制,粘贴和更改只是一点点......
如果我们应该尝试迁移,VB.NET和C#.NET之间的决定取决于我们,他们希望我们能够满足将应用程序转换为基于Web的格式的可能性.管理层不会在外部移民公司上花钱.
另一个选项来自我们的基础架构团队,该团队一直在考虑使用虚拟化来保留Visual Basic 6.0客户端 - 服务器应用程序
我们的老板希望我们提供高水平的估算和建议,但告诉我们高管们希望在2010年4月之前完成.
是的,我们嘲笑那个.
我的问题是:
有没有人有任何与虚拟化路径分享的经验,因为从开发团队的角度来看,这是一个更好的选择？它对你有用吗？有没有你会警告的pitfulls？
尽管之前的系统分析师已经给出了1 - 2年的估计,但管理层不断推出2-4个月的时间框架.任何说服他们这样做的建议都是疯了吗？
有没有人成功迁移大型VB6应用程序到网络应用程序？之前的VB6迁移问题之一有一个答案,即将部分转换为支持.NET的COM库,以掏空VB6应用程序.可以使用这种方法吗？有没有人在这里成功尝试过？
一个建议说服他们疯狂的是将任务分解成小单位,尽可能地给出估计并将其呈现给管理层.管理层往往无法给出实际估计的原因是因为他们不了解手头任务的范围.因此,如果您对任务进行切片和切块并让他们看看需要哪些实际工作,那么说服他们会更容易 - 或者重新考虑选择任务的子集并拥有一系列版本.
关于将它"移植"到.net,一种方法是将vb6程序重写为模块(COM)并将功能合并到一个新的.net应用程序中,然后在模块之后逐渐重写模块到你喜欢的.网络语言.尽管如此,这可能与任何其他方法一样混乱.