c# - 将大型 MFC 应用程序迁移到 WPF/.NET 有哪些技术？

Question

我目前正在开发一个非常大的遗留 MFC MDI 应用程序。它有大量的 UI 元素——可停靠工具栏、自定义树控件、上下文菜单等。它是一个图像处理应用程序，因此主视图使用 DirectX 和 OpenGL 呈现自己。该产品大约有 10 年的历史，这里的首要任务之一是更新它的外观和感觉。

知道 Microsoft 在提供 C++/MFC 和 .NET 之间的互操作性方面做得很好，我认为逐步迁移代码库是有意义的。我现在正在努力的是从哪里开始。

一种方法是使用 WPF 淘汰 MFC 框架，并尽可能多地重用 C++ 代码。这将使我们能够最大限度地发挥 WPF 架构的优势，但也意味着我们需要很长的开发周期才能再次完全发挥作用。

另一种方法是将 MFC 控件一次替换为对应的 WPF 控件。这将使我们能够增量工作。我对这种方法的担忧是，这意味着托管代码和非托管代码之间会有大量的连接点，我不确定从哪里开始替换主菜单和工具栏等内容。

或者我没有看到其他选项？

任何有关此主题的信息的建议或链接将不胜感激。

更新:DavidK 提出了一些很好的问题，所以我添加了这背后的动机。

1) 产品的 future 发展

此产品仍在积极开发中，并会定期添加新功能。我认为尝试慢慢迁移到 C#/WPF 会很有意义。根据我对 C#/WPF 的有限经验，我发现在 C++/MFC 中工作所带来的生产力提升是惊人的。

我们通过 WPF 获得的另一件大事是利用多头系统的能力。 MFC 应用程序仅限于单个顶级框架，因此很难利用多个显示器。

2) 员工保留和招聘

找到愿意从事 MFC 工作的开发人员变得越来越难。接触新技术对于当前开发人员的职业发展也很重要。

Answer 1

因为我已经成功地用 WPF 替换了我们的顶级 MFC UI(主框架、窗口和工具栏)，所以重温一下。

事实证明，我们的核心绘图代码只需要传递一个 HWND 即可渲染。这使得重用我们现有的大部分 C++ 代码库变得非常容易。

以下是我采用的方法的关键部分的简要概述:

• 使用 .NET HwndHost类来承载 HWND 以供 C++ 绘图代码渲染到
• 为需要向 WPF/C# UI 代码公开的任何 native C++ 代码创建 C++/CLI 包装器
• 将大部分 MFC 对话框原样保留在 native C++ 代码中。这最大限度地减少了完成 UI 所需的工作量。随着时间的推移，MFC 对话框可以迁移到 WPF。

附带说明一下，我们正在使用来自 Divelements 的 SandDock 和 SandRibbon并且到目前为止对他们非常满意。