代码之家 › 专栏 › 技术社区 › 17 of 26

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

mfc wpf c++ .net c#

29

17 of 26 · 技术社区 · 17 年前

我目前正在开发一个非常大的传统MFC MDI应用程序。它有大量的UI元素——可固定工具栏、自定义树控件、上下文菜单等。它是一个图像处理应用程序,因此主视图使用DirectX和OpenGL呈现。该产品已经有10年的历史了,这里的一个重点是更新它的外观和感觉。

知道微软在提供C++/MFC和.NET之间的互操作性方面做得很好,我认为增量迁移代码库是有意义的。我现在挣扎的是从哪里开始。

一种方法是用WPF将MFC框架撕成碎片,并尽可能重用C++代码。这将使我们最大限度地发挥WPF体系结构的优势,但这将意味着一个漫长的开发周期,直到我们再次完全发挥功能为止。

还是我没有看到其他的选择?

DavidK提出了一些很好的问题,所以我想补充一下背后的动机。

1) 产品的未来发展

该产品仍在积极开发中,并定期添加新功能。我认为尝试慢慢地向C#/WPF迁移是很有意义的。在我有限的C#/WPF经验中,我发现在C++/MFC中工作的生产率提高是惊人的。

WPF带来的另一件大事是利用多头系统的能力。MFC应用程序仅限于一个顶层框架,因此很难利用多个监视器。

2) 员工保留和招聘

5 回复 | 直到 15 年前

1

11

17 of 26 15 年前

再次讨论这个问题是因为我已经成功地用WPF替换了我们的顶级MFC UI(主框架、窗口和工具栏)。

事实证明,我们的核心绘图代码只需要交给HWND即可渲染。这使得重用现有的C++代码库变得非常容易。

下面是我采取的方法的关键部分的简要介绍:

使用.NET HwndHost 类来为C++绘图代码提供一个HWND以呈现为
MFC对话框中大部分都是在本地C++代码中。这将最大限度地减少完成UI所需的工作量。MFC对话框可以随时间迁移到WPF。

作为旁注,我们使用的是来自 Divelements 到目前为止,我和他们在一起很开心。

2

3

DavidK 17 年前

3

2

Joseph 17 年前

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

4

2

Rob 17 年前

FWIW,在此期间,您可以使用MFC功能包(VS2008 SP1提供)让您的应用程序快速呈现Office 2007外观(如果您的用户喜欢,您甚至可以添加一个功能区,尽管这会更复杂)。我在一天内使用这些新类修改了旧MFC应用程序的UI,现在,公平地说,它看起来棒极了,我的用户非常满意(你可以支持一系列的外观和配色方案。)MS选择了BCG工具包,但如果你想付少量的钱,还可以使用其他工具包(例如CodeJock)

我知道这并不能回答你的问题,但如果这只是你正在进行的UI更改,那么它可能值得一看。

5

1

Greg D 17 年前

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

考虑到您庞大但功能强大的遗留代码库,我可能会支持您的第二种方法。每次从一个控件开始,并将其设置为WPF-y。在新的托管控件和底层代码库之间创建定义良好的接口,然后使用该接口。如果你一次只做一件事,你的风险就会降低,比如WPF的学习曲线(这是非常陡峭的,imho)。

我觉得重要的是要注意,如果您要使用WinForms,我可能会建议使用前一种方法。更紧密的范例和相对平滑的学习曲线将更容易一次完成所有任务。