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

【问题标题】：What are some techniques for migrating a large MFC application to WPF/.NET?将大型 MFC 应用程序迁移到 WPF/.NET 有哪些技术？
【发布时间】：2010-10-24 14:30:14
【问题描述】：

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

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

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

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

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

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

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

1) 产品的未来发展

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

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

2) 员工保留和招聘

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

【问题讨论】：

如果可以的话，我会投不止一个赞成票。
从 MFC 迁移的理想方式是使用 QT；至少你现在的开发人员不会吵着要使用几年后就会出现的下一个很酷的 GUI 技术:)
QT 的问题在于它实际上是从 MFC 横向移动，而不是在技术和生产力方面的飞跃。除非您正在寻找跨平台解决方案，否则我认为没有充分的理由从 MFC 转到 QT。对于一家 Windows 商店来说，这一举措没有任何意义。

标签： c# .net c++ wpf mfc

【解决方案1】：

因为我已经成功地将我们的顶级 MFC UI（主框架、窗口和工具栏）替换为 WPF。

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

以下是我采用的方法的关键部分的简要说明：

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

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

【讨论】：

【解决方案2】：

我认为您没有提到更简单的方法，尽管它可能在很大程度上取决于底层逻辑与 UI 层的分离程度。

不想显得消极：您确定这值得付出努力吗？如果我从头开始编写一个大型应用程序，我现在不会从 C++ 和 MFC 开始，但是看看你在哪里，你会从重写它中真正获得什么？这会增加一个用户愿意付费的新功能吗？是否有任何用户将无法运行新版本？我不禁怀疑，通过查看一些您可以做的相对简单的事情来改善应用程序的外观，您将获得更大的投资回报。例如，它是否具有 XP 样式的清单，以便通用控件具有 XP 外观？花几天时间更新位（例如使用新样式文件对话框）会让您大部分时间获得闪亮的新外观吗？请记住，即使是最新、最闪亮的 Office 2007 也是由 Microsoft 使用普通 Win32 控件实现的。

【讨论】：

各方面的优点，我将根据调查背后的动机更新我的问题。

【解决方案3】：

FWIW，在此期间，您可以使用 MFC 功能包（与 VS2008 SP1 一起提供）为您的应用程序提供 Office 2007 的外观和感觉非常快（如果您的用户喜欢，您甚至可以添加功能区，不过这将涉及更多。）我在一天内使用这些新类修改了旧 MFC 应用程序的 UI，现在，公平地说，它看起来很棒，我的用户非常高兴（你可以支持一大堆外观和配色方案。）MS 选择了 BCG 工具包，但如果您想支付少量费用，还有其他可用的工具包（例如 CodeJock。）

我知道这并不能回答您的问题，但如果它只是您所追求的 UI 更改，那么它可能值得一看。

【讨论】：

这种方法可能很有用，因为它会给您立竿见影的效果，并且应该让您有时间在 WPF 中正确重写应用程序。
你有任何链接来解释这是如何完成的吗？我会自己做一些谷歌搜索，但如果你有一个方便的链接会更容易:)。
这里有一些优秀的示例：msdn.microsoft.com/en-us/library/bb983962.aspx 包括 MS Outlook 2007 UI、VS2008 UI 等。

【解决方案4】：

我认为你已经很好地掌握了这些策略。请注意，迁移到 WPF 的一个潜在痛点是并非每个控件都有句柄。不幸的是，这是最笨拙的互操作性场景。 AFAIK，与 MFC 和 WPF 互操作的唯一方法是通过 WindowsFormsHost。 WPF 范式也与 MFC/WinForms 完全不同，因此可能存在一些翻译问题。

鉴于您庞大但功能强大的遗留代码库，我可能会支持您的第二种方法。一次从一个控件开始，并将其设为 WPF-y。在您的新托管控件和底层代码库之间创建一个定义明确的接口，然后针对该接口工作。如果您一次只做一个，那么您将面临风险较低的问题：WPF 的学习曲线（恕我直言，非常陡峭）。

我觉得重要的是要注意，如果您要使用 WinForms，我可能会建议前一种方法。更接近的范式和相对平滑的学习曲线会更容易一次性完成。

【讨论】：

我发现的一件事是如何在 MFC 中托管 WPF 内容：stackoverflow.com/questions/829952/…

【解决方案5】：

我以前必须在使用 WinForms 的项目中做同样的事情。我们需要将 MFC 项目迁移到 .NET 1.1，我们决定采用 MFC 应用程序的所有核心功能并围绕所有这些功能编写托管包装器。然后我们编写了一个 WinForms 前端，并一点一点地插入遗留的 c++ 代码。我认为从长远来看，我们做出了正确的选择。我无法想象如果我们试图同时保留 MFC 前端，我们会怎么做。

【讨论】：