WinForms是死了还是濒临死亡？
不是。它没有得到显着的进一步发展（即没有新的主要添加），但在.NET 4中得到了完全支持，例如。
WPF是学习的好技术吗？
是的。
它是未来，只是一个阶段，还是可以与WinForms并肩前行的技术？
计划最终转移到WPF，但也理解存在大量现有的用WinForms编写的代码库，并且没有重写为WPF的业务案例。因此，WinForms仍然得到支持。
另外，任何经验都很好听，特别是那些广泛使用过两者的人。您如何在这两个框架中实现类似功能的体验？
总的来说，WPF更具表现力。如果将框架看作一组乐高积木，可以以各种方式组合WinForms积木较大 - 每个积木都做很多事情 - 因此可供组合的方式较少。当您需要某些-但不完全像现有积木所做的那样时，通常必须从头开始编写自己的积木。在WPF中，积木要小得多，并且可以以许多有趣甚至令人惊讶的方式组合。
作为一个具体的例子，请考虑WPF Button是一个容器，可以托管任意内容 - 不仅仅是WinForms中的图像+文本，而是绝对任何其他WPF控件或一组控件。
与WinForms相比，WPF在编写动态布局方面要容易得多。后者也有布局，但问题在于在可视化设计器中使用它们非常麻烦，通过代码编写WinForms组件初始化非常繁琐。使用WPF，您只需手动编写XAML标记，布局（以及控件树总体）在XML中自然表示。
部分源于上述原因，我发现WPF更容易本地化。首先，这是因为您确实需要动态布局才能进行本地化（因为您不知道所有区域设置中字符串的长度）。 WinForms解决此问题的方法是将控件位置和大小视为“可本地化属性” - 因此，如果翻译人员发现字符串不适合，则应自行重新排列表单上的控件。在WPF中，动态布局是默认方法，因此本地化程序只需处理字符串。
WPF绑定框架相当强大（即使冗长，由于缺少内联转换器），并且大力推广MVP以及一般的模型/视图分离。在2.0+的WinForms中也可以实现这一点，并且我也尝试在那里做到这一点，但这更加繁琐，特别是对于空值处理，并且有时可能会相当有错误。
一个特别痛点是WinForms设计器与源代码控制的交互方式。这里有两个类似的问题。首先，设计器将编辑的窗体序列化为代码，并且有时候布局中非常微小的更改就会使设计器生成完全不同的代码（如果您编辑工具栏，则尤其明显），因为它会重新排列代码行——实际上，它只更改了一行上的单个属性值，但也重新排序了所有内容。这导致历史记录中有很多噪音（很难通过差异查看确切的更改），但更重要的是，这意味着合并这样的文件是一个主要的头疼问题。当两个人同时使用同一个窗体进行工作，然后一个人提交他的更改，另一个人试图提交时，发现文件在此期间已更改，试图合并，看到差异，并跳出最近的窗口时，通常会发生这种情况。还有第三方组件的问题。WinForms已经存在很长一段时间了，有许多可用于它的组件，其中很多非常成熟。WPF相对年轻，仍在经历成长的痛苦，因此大多数第三方解决方案也是如此。
我在WPF中特别讨厌的一个问题是它抗锯齿文本的方式——大多数人认为这种方式在小字体大小时与普通的Windows ClearType相比质量要差得多；请参见此错误报告以获取更多信息。这在WPF 4中得到了修复，但该版本尚未发布，即使发布后，您可能仍然想坚持使用经过验证的3.5 SP1一段时间；而且这个修复程序没有被反向移植。
WinForms并非已经过时或将要淘汰……只是如果没有大量的工作，无法提供与WPF相同的用户体验。 它们只是更老的技术。
WPF是学习的好技术。它可以提供更丰富的用户体验，并且需要较少的工作。
使用WPF的模型肯定不同于WinForms。我两者都用过（WinForms比WPF / Silverlight使用得更多），对我来说最困难的转换是：
XAML，如果您具有使用其他标记语言（如MXML）的经验，则不会太糟糕。
DataBinding
接口事件处理（MouseOver效果，时间轴等）
WinForms离死亡/衰退还有很长一段距离。 WPF只是一种更新的处理UI的方法，因为它推广了在WinForms中更加困难的事情。像将UI后面的模型与实际UI分离，以便可以轻松测试等都是重要因素。
学习它绝对是值得的，但一定要学习“WPF方式”创建屏幕，而不仅仅是将你的WinForms方式适配到其中。这是一种不同的编码方式。
2016年的看法:
虽然这个问题已经有些老了，但我认为在这个问题上加上一个结论是很合适的。为什么呢？因为即使到了现在（2016年），我仍然听到在企业环境中工作的开发人员仍在问这个问题。
是的，七年过去了，WinForms仍然在企业环境中存活，并且仍然得到了微软的支持。Google Trends显示自2005年中期以来，对WinForms的关注度缓慢而稳定地下降，目前的兴趣约为2005年的三分之一。
WPF在2009年左右引起了轰动，但从未完全成为新UI开发的事实标准。Google Trends显示，WPF的关注度在2009年至2011年之间达到峰值，然后下降速度比WinForms快。目前的搜索兴趣是2011年的一半，但仍然接近WinForms当前的搜索兴趣的两倍。
那么现在开发人员都在用什么呢？基于Web的UI因移动浏览的兴起而大受欢迎。你可以就如何编写Web UI进行争论（AngularJS + WebAPI? ASP.NET MVC? React? 所有这些都在Google Trends上呈上升趋势）。无论您使用哪种技术，很难否认一次编写（响应性）UI，它能够在几乎所有设备和平台上运行的吸引力。云托管服务通过提供低前期基础设施投资的几乎即时/无限缩放进一步推动了向Web的转变。
因此，今天我强烈建议向Web UI迈进，因为它可能会增加应用程序的寿命-这些应用程序通常需要在企业环境中长时间存在。或者，如果您是微软基础的开发人员从事移动开发，Xamarin值得一试。
WinForms在企业环境中可能会长期存在。对于许多目的而言，它们足够好用。许多项目都基于WinForms，并且许多公司将坚持使用该技术而不是混合使用。
话虽如此，WPF才是未来。它是一种更高效、更有能力的UI技术，值得学习。
WinForms和WPF可以共存于单个应用程序中。这可能是它们被引入公司的最常见方式（除了小型概念验证项目）。
当然不是。
Winforms更容易使用（如果你还不了解WPF的话），而且WPF与Winforms模型有很大的区别。
如果你想要一个简单的GUI（标准表单内容），那就用Winforms。如果你想要一些更奇特的东西，并且有时间，那就选择WPF。
我相信在未来，WPF会成为事实上的标准。但现在，如果我想要快速干净的东西，我仍然坚持使用Winforms。
值得一提的是，许多应用程序已经在使用Winforms - 这意味着维护工作通常会涉及到WinForms，所以不要轻视它。
WinForms并没有死。谷歌搜索“winforms C# jobs”，你会发现有很多相关工作。WPF是热门技术，但它仍然相对较新。在我看来，它还需要两到三年才能成为主流。
这里有一篇关于WinForms和WPF的好博客文章。总体思路是要明智选择，也就是说没有一个胜过另一个。每个都有不同的功能子集。
然而，在WPF和WinForms之间做出决定是另一回事。当然，WPF是新的热门技术，而WinForms已经老旧了，但它是否是正确的选择呢？显然，“这取决于”具体情况，微软正在继续提供和支持WinForms，因此它不会很快消失。那么，选择WPF而不是WinForms的令人信服的因素是什么？Karl在他的WPF业务应用程序系列中暗示了选择WPF而不是WinForms的原因，但对于某些人来说，这些原因可能是微妙的。
我个人更喜欢WPF，因为我是从Web开发者开始的，发现标记语言XAML更自然。
我认为在WPF变得更加主流之前学习它绝对是值得的，不断提高技能并了解新技术的经验和知识总是一种加分项，尤其是如果WPF未来被广泛使用。
此外，虽然编写xaml标记与创建表单非常不同，但与编写html并没有太大的不同，如果你曾从事过Web开发，那么这应该不会是一个难以逾越的难关。
虽然WinForms是一种较老的技术，但这并不意味着它将永远消失。我们公司仍有使用VB6编写的应用程序。我们的开发部门只有一半使用.NET-我们分为三个团队，其中一个团队仍在使用.NET 1.1，另一个团队正在使用.NET 2，而我所在的团队则正在使用.NET 3.5（可以说我们很幸运！）
我们开始在一个新项目中使用WPF，坦白说，很难回到WinForms。有很多我再也无法离开的好东西。
不过，有一个建议。虽然你可以用WPF做更复杂的布局（比如说，一个按钮或者几乎任何东西都可以包含其他东西，比如图片、文本框等等），但是一些其他“基础”功能在WinForm中很难复制。 例如：在WPF工具包出现之前，WPF没有数据网格和日期选择器，所以你必须自己做。此外，它仍然没有MaskTextBox，你必须自己做或从第三方下载。最后一个我遇到的问题是关于Treeview的：叶子和父节点之间的线条不显示。
话虽如此，在大多数方面仍然比WinForm好得多。
