是否有一种实用方式让我们慢慢将WinForms应用程序发展为WPF，而不会为奇怪的互操作方案创建支持梦魇？
背景资料：
我们有一个大型战舰灰色WinForms应用程序，大约由60-75个用户的内部组使用。我们开始遇到可以看到在WPF中使用应用程序带来好处的地方，但这还不足以证明大型项目完全重写它的理由。应用程序中的所有屏幕都是自包含的WinForms用户控件，而WinForms应用程序只是一个处理菜单，打开/关闭表单，提供一些共享帮助方法等的shell ...
到目前为止，我们最好的想法是将shell应用程序转换为WPF，然后在其中托管WinForms用户控件。我们认为我们可以随着时间的推移转换用户控件，将这些更改与具有足够业务价值的计划相结合，以支持额外的工作。我担心互操作性能如何以及它将如何影响性能。我也关注我们如何过渡到应用程序的新外观。让shell应用程序看起来很时髦，然后在其中托管旧的战舰灰色用户控件似乎很奇怪，在WPF中创建shell应用程序并使其看起来就像在WinForms中一样。
如果其中一个Caliburn，Prism或其他类似框架能够缓解这种转变，我们也愿意探索这些选择。
答案 0 :(得分：11)
我们处于类似情况并选择了以下路径：开始时我们开始在应用程序shell（仍然是WinForms）中托管一些WPF窗口。当然有一些明显的差异，但我们通过降低新窗口故意减少差异。我们认为，当我们转换剩余的窗口/控件时，将更容易“升级”到更生动的体验，因为UI将完全是WPF，我们可以让图形设计师基于XAML来实现他们的魔力。 / p>
我们现在已经达到了大多数窗口都是WPF的程度。我们已经开始将WinForms shell应用程序转换为托管其余WinForms的基于WPF的shell应用程序。我们的颜色有点暗淡，但是用户已经开始注意到它们之间的区别，尽管它很小，但我们的用户仍然喜欢渐进的积极变化。不会太久，我们将退休最后的WinForm。当我们让我们的图形设计师脱离皮带时，这就是重点！
关于性能：我当然不能做出一般性陈述，因为它在很大程度上取决于你的特定控件/窗口。在我们的产品（几百个窗口）中，我们没有发现任何与WPF和WinForms混合相关的重大性能问题。
我们没有调查任何框架，所以我担心我无法评论这些框架。
答案 1 :(得分：4)
很好的问题，目前WPF中的大多数工作都涉及将旧的WinForms应用程序转换为WPF。根据我的经验，最佳案例场景是根据旧的应用程序/要求从头开始构建应用程序。幸运的是，我参与了一个项目的一部分，我们从头开始重新编写应用程序，我确信这需要花费更少的时间/投资，然后将两者混合使用。
我个人觉得如果我们尝试将两者混合起来会造成混乱。另一点是，有效地设计混合应用程序将很困难。
在我目前的项目（这是一个过去10年的大型项目）中，我们正在逐个模块地转换应用程序。幸运的是，我们的应用程序包含各种较小的应用程序，因此逐个转换它们更容易。在你的情况下，我会说你确定可以完全转换为WPF的区域并开始在WPF中构建它们，如此处所示 -
Windows窗体 - WPF互操作性常见问题解答： http://windowsclient.net/learn/integration.aspx
我还建议使用一些工具将Windows窗体转换为XAML（WPF）;这肯定会帮助你节省一些时间。
Windows窗体到WPF转换器： http://wf2wpf.codeplex.com/
Windows窗体到XAML转换器： http://www.ingeniumsoft.com/Products/WinForm2XAML/tabid/63/language/en-US/Default.aspx
Windows窗体到Windows演示文稿 基础转换器： http://www.spiderwan.com/spiderwan/ConvertWinFormToWPF/WinFormToWPF.aspx