一次开始将表单转换为.NET是一个好主意，然后您可以通过COM-interop从VB6应用程序调用它。
这样，在流程结束时，您只需将VB6应用程序的“shell”转换为新的.NET应用程序，并且所有表单都可以在.NET中使用。
有更好的策略吗？
答案 0 :(得分：3)
如果是我，我会立刻撕掉创可贴。我认为在您的应用程序中使用中间状态[.NET Forms和COM-interop]没有任何好处，因为它只会增加不必要的复杂性。
答案 1 :(得分：3)
我们有一个VB6应用程序，它也被移植到.NET，我们使用COM-Interop策略。所有新功能都可以在.NET中实现，只有GUI内容仍然是VB;同时，我们可以独立开发新的GUI。
如果你还不知道这一点，你可以在不使用注册表的情况下进行COM Interop（因为这会给我们带来一些问题）免费注册COM Interop ：
答案 2 :(得分：2)
有很多关于转换策略的建议。
答案 3 :(得分：1)
您描述的零碎方法将创造额外的工作，因为您将尝试使VB6和.Net代码共存，除了最简单的应用程序之外，其他任何问题都充满了问题。在某个地方你可能会遇到一个可能是一个暴徒的陷阱。
我建议采用以下方法（基于成功将600,000行VB6应用程序迁移到.Net）：
确保您现有的VB6代码库已正确版本控制并标记。 为VB6代码库编写回归测试，最好是自动化的。 获取已知的VB6代码标签基线，并将其作为单个实体迁移到.Net。您的客户继续使用VB6版本。 对迁移的代码运行回归测试。 当所有测试通过后，将.Net代码应用于自您获取原始VB6基线以来发生的任何VB6更改。 交付UAT，然后生活。
答案 4 :(得分：0)
您是否会一次执行大型复杂数据转换，您的系统会长时间使用一个，另一个或两个数据模型？显然，这是在寻找麻烦和复杂性。大数据转换的最佳实践是以尽可能短的停机时间使整个数据模型达到所需的最终状态的方式进行。相同的推理适用于大规模代码转换。在增加劳动力成本和技术风险方面，在零碎和延长的时间内进行这些操作是一件麻烦事。
IMO，更好的方法是为您的.NET代码制定最终状态开发和架构标准，然后投资一个流程，帮助您以符合这些标准的方式有效地重写您的系统并准确地保留传统业务规则和功能行为。长期过渡和复杂的混合/中间解决方案只是一个止损，最好是导致业务问题和最坏的项目失败 - 应该避免它们。更好的方法将允许您以内部一致，独立和结构良好的部分将旧软件交付到新平台。此外，以更少，更大的部件提供迁移将比许多小部件更有效且更少破坏性。
使这种方法可行的关键是使用下一代VB6 / COM / ASP到.NET工具，允许您迭代校准，定制和验证自动重写过程，以平衡自动转换与手动工作。 Great Migrations中的工具专门用于实现此方法。我们称之为“工具辅助重写”。我们在几个大型迁移项目中使用了这种方法，包括将VB6 / COM的1.2M LOC应用程序组合升级到重新设计的C＃/ .NET。
免责声明：我为Great Migrations工作。