我的公司拥有大量用VB6编写的传统应用程序。
我们处于从将VB6应用程序迁移到.NET（特别是3.5）的转换过程中。
将VB6转换为.NET的最佳策略是什么？
注意：以下更新应转至“项目管理”，与主要问题无关。
[更新] ：感谢您对目前的反馈。现在有了 弹出的更多问题是
- 您如何指定开发人员开发新应用程序？
- 是否应该有一个特殊的一次性升级部门进行转换 遗留应用程序到新的？或者应该 每个开发者都参加 转换过程？
- 只有高级开发人员参与转换吗？初级 开发商？还是混合？
似乎，我想的越多 这个问题，更多的问题只是表明 起来。
答案 0 :(得分：8)
显然，这是一项涉及大量工作的重大工作 因此，我的建议是将其视为一个非常长期的项目。
明确目标，解决安全性，弹性，可维护性和应用程序未来等主要问题。
一旦利益相关者同意，开发一个原型系统来测试你的假设，在那里你可以试用C＃vrs VB.net或MVC vrs Webforms。 我会为此分配您最好的开发人员。
然后从一个小型遗留系统开始，构建您将在其他领域重复使用的核心组件 在这个阶段，从您的高级开发人员开始，但每个人都必须参与并熟悉新框架 这将确保每个人都在同一时间接受培训，不会留下任何人 根据您拥有的应用程序数量，我会轮换开发人员，因此所有系统都可以从中受益。
此外，所有新作品必须使用.net语言而不是VB6。
逐步转换每个旧版应用程序。 （如果他们正在改变或者更新它们有明显的好处，我只会转换它们。）
这应该为您提供一个可靠的框架，以便继续使用，同时仍然确保您的迁移不会妨碍用户的功能。
例如：
我曾在一家拥有大约40个VB应用程序的公司工作过
随着时间的推移，我们已将所有这些迁移到C＃，现在（5年后），我们有大约150个c＃应用程序（全部在.net 2中）。
这些都共享一个共同的框架，使它们易于维护，并在必要时扩展。
答案 1 :(得分：7)
尝试使用支持COM的.NET库替换核心功能。通过将功能逐位移动到.NET，“挖空”现有的VB6应用程序。
小心完全重写。虽然他们很诱人“因为它是一个干净利落” - 通常是疯狂的！阅读Michael Feathers的“有效使用遗留代码”作为准备。虽然这本书没有具体涉及“从一种语言转移到另一种语言”，但它确实显示了你将遇到的许多现实世界的陷阱。
我认为所有开发人员都应该定义他们在以前开发的旧版应用上进行迁移工作的时间段。由于他们已经拥有领域知识并且知道问题空间，因此他们应该是最有效率的。
答案 2 :(得分：3)
以下是我answer对类似问题的修改。
自动转换大型程序是比重写更好的选择。这是一个常见的陷阱，开始乐观地重写一大块软件，在旧架构中修复一些众所周知的缺陷，早日取得良好的进展，然后陷入你刚认为理所当然的功能陷入困境中年份。在这一点上，您的管理层开始变得神秘莫测，一切都会变得非常不舒服。
...这是微软的一篇博文agrees with me：
我在.NET早期工作过的许多公司首先考虑的是重写，部分原因是他们在迁移到.NET的同时强烈希望改进底层架构和代码结构。不幸的是，许多项目遇到了困难，有些项目从未完成。他们试图解决的问题太大了
这个优秀的Microsoft page建议使用两个第三方迁移工具，而不是功能不足的内置VB.NET升级向导 - Artinsoft和CodeArchitects VBMigration。 Artinsoft编写了内置的VB.NET升级向导，这是他们的改进版本。 CodeArchitects由Francesco Balena创建，他在VB6和VB.NET上编写了一些classic books。
同一个微软页面也说：
对.NET执行完全重写要花费更多，而且难以做好[转换] ...我们只会在少数情况下推荐这种方法。
基于他们协助许多迁移的经验，我重复上面的微软建议 - “完全改写远比转换[我的重点]更加昂贵和困难 - 一个扁平的矛盾可能需要同一时间的假设。如果你想改进VB6的结构，那么逐步重构可能比重写更具成本效益。
答案 3 :(得分：2)
当然，C＃vs VB.Net只是其中的一部分。
例如，另一件需要考虑的事情是，如果你想利用这个机会将这些应用程序移动到内部网，如果你还没有。或者你想深入研究微软的堆栈有多深。例如，Winforms是否足够，或者您是否想要使用WPF。
答案 4 :(得分：1)
答案 5 :(得分：1)
您可能会发现以下文章有用： http://www.vsj.co.uk/articles/display.asp?id=756