有没有实用 如何让我们慢慢地将 WinForms 应用程序发展为 WPF，而不会为我们自己带来奇怪的互操作场景的支持噩梦？
背景资料:
我们有一个大型战舰灰色 WinForms 应用程序，它被大约 60-75 名用户的内部组大量使用。我们开始遇到可以从 WPF 中看到应用程序的一些好处的地方，但不足以证明一个大型项目完全重写它是合理的。应用程序中的所有屏幕都是独立的 WinForms 用户控件，而 WinForms 应用程序只是一个 shell 程序，用于处理菜单、打开/关闭表单、提供一些共享的辅助方法等...
到目前为止，我们最好的想法是将 shell 应用程序转换为 WPF，然后在其中托管 WinForms 用户控件。我们认为我们可以随着时间的推移转换用户控件，将这些更改与具有足够业务值(value)的计划联系起来，以支持额外的工作。我担心互操作的工作情况以及它将如何影响性能。我还担心我们如何过渡到应用程序的新外观。让 shell 应用程序看起来很时髦，然后在其中托管旧的战舰灰色用户控件似乎很奇怪，而且在 WPF 中创建 shell 应用程序并使其看起来就像在 WinForms 中一样似乎也很奇怪。
如果 Caliburn、Prism 或其他类似框架中的一个可以简化过渡，我们也愿意探索这些选项。
最佳答案
我们处于类似的情况并选择了以下路径: 一开始我们开始在应用程序 shell (仍然是 WinForms)中托管一些 WPF 窗口。当然，有一些明显的差异，但我们通过调低新 window 来故意减少差异。我们认为，当我们转换剩余的窗口/控件时，将更容易“升级”到更生动的体验，因为 UI 将完全是 WPF，我们可以让图形设计人员基于 XAML 发挥他们的魔力。
我们现在已经达到了大多数窗口都是 WPF 的地步。我们已经开始将 WinForms shell 应用程序转换为托管其余 WinForms 的基于 WPF 的 shell 应用程序的过程。我们仍然有一些暗淡的颜色，但用户已经开始注意到差异，虽然它很小，但我们的用户仍然喜欢增量的积极变化。不会太久，我们将淘汰最后一个 WinForm。这将是我们让我们的图形设计师摆脱束缚的关键!
至于性能:我当然不能做一般性声明，因为它在很大程度上取决于您的特定控件/窗口。在我们的产品(数百个窗口)中，我们没有发现任何与 WPF 和 WinForms 混合相关的重大性能问题。
我们没有研究任何框架，所以恐怕我不能评论这些。
关于.net - WinForms 到 WPF - 我们如何从这里到达那里？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3457764/