Rob Relyea pointed out a good debate going on between some folks about WinForms vs. WPF - see here and here and here.  Good points made on both sides of the argument.  I thought I would share my thoughts on the subject.  <dramatic pause to keep my three readers in suspense....>

Both are right! ;-)  Here is the way I look at it.  WinForms is a dead-end technology for the most part.  It will take a long time to get to the end of the road, however.  WPF is the future of building applications on Windows.  That does not mean that you should avoid WinForms like the plague.  Today, I would say a large number of enterprise apps are served very well by WinForms.  Even if WinForms is not going to be the programming model of choice in the long term, it will be supported for a very long time so investing in it today is not a bad thing.  So don't feel guilty picking WinForms just because WPF is out there.

Having said all that, WPF is also a good choice for a range of applications today.  The various reasons for good reasons to pick WPF are laid out by the other offers, so I won't rehash them all here.  On area, however, that may not have been clearly articulated by the others is task-based UIs.  If you want to build applications that are geared to accomplishing tasks (or a series of tasks), WPF really helps because of your ability to create very intuitive and visually rich interfaces.  This in some ways is a lot like skinning, but goes beyond look and feel.

The things that are holding back WPF adoption are a few things:

--- Non-beta tooling is still a very big challenge from the developer side of the equation.

--- To get the full benefits of WPF from a UI perspective, you really need someone that understands UI design.  WPF apps that are poorly done can be uglier than an equivalent WinForm app with out a lot of effort. ;-)

--- Limited control pallet.  DataGrid is the biggie, but even simple ones like a calendar control still make WinForms a clear leader.  Sure, there are community and third party controls, and its not that hard to roll your own. But a developer's comfort level with a framework is a lot lower if he feels it is incomplete, and a lack of controls makes it feel that way.

Those are the main ones I think.  I may come up with others if I thought about more, but I'm snapping this out before the kids head off to school.

A colleague of mine, Shannon Braun, is an independent consultant that has been working on a large WPF project.  He and I are going to do a podcast interview in the near future to get some real world thoughts on using WPF for a real enterprise class application.