c# - Visual Studio 6 中 C++ 项目的推荐迁移策略

Question

对于使用 Visual Studio 6 用 C++ 编写的大型应用程序，进入现代时代的最佳方式是什么？

我想采用增量方法，我们慢慢地移动部分代码并将新功能编写到 C# 中，然后将其编译成可以从遗留应用程序引用的库或 dll。

这是可能的，最好的方法是什么？

编辑 :在这一点上，我们仅限于 Express 版本，我认为这些版本不允许使用我们当前应用程序中大量使用的 MFC 库。它也是一个相当大的应用程序，具有很多硬件依赖性，因此我认为不会进行大规模迁移。

编辑 2 :我们已经研究过用 C# 编写 COM 包装的组件，但没有 COM 经验，这既可怕又复杂。是否可以生成一个带有直接 C 接口(interface)的 C# dll，其中隐藏了所有托管的优点？还是 COM 是必要的邪恶？

Answer 1

面对同样的任务，我的策略是这样的:

确定我们希望通过转向 2010 年的发展获得什么——它可能是

改进的质量保证:单元测试、模拟是现代开发工具的一部分

更流畅的用户界面:WPF 提供了现代的外观和感觉。

生产力:在某些领域，.NET 开发比 C++ 开发更具生产力

支持:通过改进和错误修正支持新工具。

确定系统的哪些部分不会从迁移到 C# 中获益:

硬件访问，低级算法代码

几乎大多数定制的非 UI 工作代码 - 如果它已经工作没有意义将其扔掉

确定系统的哪些部分需要迁移到 c#。对于这些部分，请确保 C++ 中的当前实现是解耦和模块化的，以便可以换出这些部分。如果应用程序是一个整体，那么将需要大量的工作来重构应用程序，以便它可以被分解并选择在 c# 中重新实现的部分。 (可以不进行任何重构，而只专注于在 c# 中实现新的应用程序功能。)

既然您已经确定了哪些部分将保留在 C++ 中，哪些部分将在 c# 中实现，(或者只是规定新功能在 c# 中)，那么重点将转向如何将 c# 和 c++ 集成到单个解决方案中

使用 COM 包装器 - 如果您现有的 C++ 项目很好地利用了 OO，这通常并不像看起来那么困难。使用 MSVC 6，您可以使用 ATL 类将您的类公开为 COM 组件。

直接集成原生和c#代码。集成“遗留”编译代码需要一个中间 DLL - 见 here详情。

混合 MFC UI 和 c# UI 可能无法实现，也不建议这样做，因为它会产生两种不同风格(1990 年代灰色和 2010 氛围)的 UI 混合。专注于实现增量迁移更简单，例如在 C# 中实现新的应用程序代码并从 native C++ 代码调用它。这使得迁移的 c# 代码量很小。随着您对 2010 开发的深入了解，您可以采用无法增量迁移的较大块，例如 UI。