我在大型C应用程序上工作(大约450,000行代码)，我们经常遇到桌面堆和GDI句柄泄漏的问题。 WPF解决了这些问题，但是我不知道什么是升级的最佳方法(我希望这将花费很长时间)。该应用程序只有几种形式，但是它们可以包含许多不同的用户控件集，这些控件以编程方式确定。

这是公司内部的应用程序，因此我们的发布周期非常短(通常为3周的发布周期)。

是否有一些逐步升级的途径，还是我们必须付出巨大的努力才能取得成功？

解决方案

我们是否使用大量的用户控件？ WPF可以承载Winform控件，因此我们可以分段将各个部分引入主窗体。

WPF允许我们将Windows窗体用户控件嵌入到WPF应用程序中，这可以以较小的步骤进行过渡。

看一下WPF文档中的WindowsFormsHost类。

关于将.NET 2.0 Winform应用程序迁移到WPF，有一个非常有趣的白皮书，请参阅向.NET 3.5应用程序发展。

论文摘要：
在本文中，Im将概述将Microsoft .NET应用程序从1.x / 2.x升级到3.x时必须面对的一些思想过程，决策和问题。我将研究如何帮助客户采用新技术，同时仍保持业务可接受的发布时间表。

我们可以从创建WPF主机开始。

然后，我们可以使用<WindowsFormHost />控件托管当前应用程序。然后，我建议在WPF中创建一个新控件库。一次可以创建一个控件(我建议将它们设置为自定义控件，而不是用户控件)。在每个控件的样式内，可以从使用<ElementHost />控件开始，以包括"旧的" Windows窗体控件。然后，我们可以花时间重构和重新创建每个控件作为完整的WPF。

我认为创建控件包装程序和为该应用程序设计WPF主机仍然需要花些功夫。我不确定应用程序的大小或者用户控件的复杂性，因此不确定要为我们付出多少努力。相对而言，以这种方式使应用程序在WPF中启动和运行的工作量大大减少，工作速度也大大加快。

我不会只是这样做而忘记它，因为我们可能会遇到控件相互重叠的问题(Windows窗体在WPF中不能很好地工作，尤其是在透明胶片和其他视觉效果中)

请向我们更新该项目的状态，或者如果我们需要更具体的指导，请提供更多技术信息。谢谢 ：)

我认为我们不只是在寻找ElementHost来放置我们庞大的Winforms应用程序。无论如何，这并不是向WPF的真正移植。
考虑该线程的答案，克服从Winforms迁移到WPF的更大障碍是什么？这将非常有帮助。