Disclaimer: I'm not generally a Windows Client developer.
I presume that WPF is intended to eventually replace WinForms altogether, but for now, they both are shipping.
My question is, when is one more appropriate than another? Should we be leaving Winforms to legacy and creating new Windows Clients in WPF only?
WPF requires either Vista or Windows XP SP2, which is not an onerous requirement but it is a relevant one. If you want to run on Windows 2000 (which some people still do), then WPF won't work for you.
WPF is also a newer technology and not as proven as WinForms so you might choose WinForms as a less risky option, particularly for larger applications.
That being said, yes WPF is the future. Visual Studio 2010 is being rewritten in WPF, which will probably be the largest WPF application to date and it will also be a real test for the technology.
Obviously legacy Winforms apps would be another situation where it is the correct choice.
Both of technologies have their pros and cons. In large application with "classic" UI I'd use winforms. In application which require rich user interface (skinning, animations, changing user interface) I'd choose WPF. Please check this article comparing WPF and Winforms.
Consider WPF if interface design is important to you, because WPF can deliver better UI experience. But Winforms has on it's side the years of evolution, so it's proven to work and you can find many versed programmers for that platform.
Also portability may be an issue, WPF only works with XP SP2 and up.
Also, WPF has a high curve of learning, meaning it's not easy to deliver a quality product without having specific WPF experience.
Well, one answer is "when you have to support 1.1 or 2.0", since WPF is part of .NET 3.0. There are known OS limitations for WPF, and there is an obvious skills issue: if you have a team of developers that know winforms, then it may be easier to turn out robust code with winforms. However, if you are writing a lot of UI code it is probably worth beginning to pick up WPF at some point.
WPF also shares a lot in common with Silverlight, so it has transferable benefits.
Multiple answers make the claim that you should use WPF if interface design is "important to you" but thats pretty vague. Interface design is always "important"
WPF makes it much easier to hand off the forms design work to an actual designer, not a developer in designer's clothing. If thats something you'd like to do, WPF is your answer. If the classic windows styled buttons are fine, then WinForms is probably the way to go.
WPF comes with many advantages such as superb data binding features, separation of concerns, separation of design and logic etc...
As a developer I enjoy the ability to define my UI using XAML as opposed to being tied to the Windows Forms designer and I feel good knowing I can count on another designer to make my app look good.
Personally I don't care older versions of Windows are not supported, but one of the big problems with WPF is that is is not (currently/ever) supported by Mono (http://www.mono-project.com) so WPF apps will not run on Mac OS or Linux. (Altough Silverlight applications will).
If you have the time and resources to invest in learning WPF, do it! Even if you're going to be writing Silverlight applications to support multiple OS's.
If you need desktop applications to run on multiple OS's stick with SWF.
i don't agree with some of the answers here. WPF is really well suited for Line of Business applications. (the frog design LoB client is the best example). And besides all the possibilities to have your UI look eye candy (which is not necessary in business applications) , wpf offers a lot more for you. the data binding and templating features are just superior to winforms. it also offers a far better way for separating code and presentation. we've used WPF for 2 LoB applications in teams with no more than 2-3 developers successfully.
the biggest problem you will face is probably the steep learning curve of wpf (compared to winforms) which will decrease development speed with developers not used to wpf.
For conversion projects (from VB6), it's hard to get a team to switch to WPF. Besides learning curve, people are already used to the old interface. WinForms, although being phased out, will be around for a long time still.
After 3 months of trying to hammer out a LOB application on WPF, I reached a point of considering turning back to WinForms for my project, and in researching other people's opinions, came across this thread...
Yes, WPF is a brilliant technology and it has benefits that span far beyond mere eye-candy... the templating and binding capabilities are great examples. The whole object model offers more flexibility and broader possibilities. That doesn't, however, make it the defacto platform for future line-of-business apps.
The "problems" which WPF solves in terms of seperating GUI from business logic aren't problems which can't be readily solved in Winforms by simply starting with the right architecture and mind-set. Even the object-path binding capabilities of WPF can be reproduced in WinForms with some very simple helper classes. The data template capabilities of WPF are very nice, but again they're nothing that you can't simulate in WinForms on those rare occasions when you absolutely don't know exactly what objects you're going to represent on any given part of the screen.
Where WinForms races ahead is in terms of maturity. You can't swing a dead cat on Google without hitting some blog where someone has solved a WinForms problem for you. WPF, on the other hand, has comparatively less learning resources available, fewer custom controls available, and hasn't had as many of it's teething problems solved.
At the peak of making a WPF vs Winforms decision has got to be the maturity of the development environment. Winforms is editors are slick, responsive and intuitive. Feedback about errors gets to you instantly, the solutions are usually obvious, and the compile->debug->edit cycle in Winforms is very quick.
WPF apps, on the other hand, have comparatively pathetic design time support, with the design view all-too ready to chicken out at the first encounter of an error, often requiring a project build after the fix before the designer is willing to kick in again. Drag'n'drop of components from the toolbox might as well not be supported, given the vast range of circumstances under which it either doesn't work at all, or yields completely unintuitive results. Despite the promise of the WpfToolkit, there still isn't a usable DataGrid for WPF that yields any kind of resonable performance or design time friendlyness.
Debugging WPF apps is a bit like the old ASP.NET debugging paradigm... hit F5 -> wait -> launch -> error -> stop -> fix -> hit F5 -> wait -> launch -> error -> groan -> stop -> fix -> hit F5.... all XAML is locked which your program is running, and tracking down XAML specific problems is often tedious.
The botton line, simply put, is that the development tools for WinForms are going to have you banging out front-ends in a fraction of the time of a WPF application... especially if you're creating master-detail grids or spreadsheet like interfaces, which most LOB have. With Winforms, you start with 90% of the work already done for you.
I'm a huge fan of the WPF architecture. I just wish the design-time tool-set didn't feel like a pre-alpha debug-build.
Edit: This answer was posted about .NET 3.5 + VS2008, but .NET 4.0 with VS2010 ships with a WPF data grid. While many improvements have been made to the new WPF development experience, my answer here remains unchanged, and I'd like to add the following suggestion:
If you're in a rush to do RAD development, go with Winforms. If you're looking to produce a well architected, maintainable, scalable, resource firendly, multi-user Line-Of-Business app, consider ASP.NET MVC + HTML 5 + jQuery... my projects with these technologies have resulted in better outcomes, sooner, for my customers. MVC offers all of the same templating that WPF does, and jQuery enables animations and complex interactions. More importantly, an ASP.NET MVC + jQuery solution doesn't require your end users to have modern desktops with descent graphics hardware.
The programming model for WPF is more open and flexible than Winforms is, but like ASP.NET MVC, it requires a little more discipline in terms of correctly implements Model-View-ViewModel patterns.
My first LOB application with WPF ended up an utter failuire because it was a resource hog which brought my end-user's very-low-end laptops grinding to a halt... and this was ultimately because I just lept in with WPF + Linq-To-SQL and expected a good result... and this is where WPF diverges so strongly from WinForms... in Winforms you can get away with that sort of thing. WPF is much hevier on resources than Winforms, and if you don't architect your app to be lean, you end up with a 100-pound gorilla.
Don't shy away from WPF... explore it. But be aware that the acceptable sins of winforms coding won't produce good results in WPF. They're fundamentally different engines, which lend themselves to fundamentally different coding patterns.
Last Word: If you do go ahead with WPF, get well acquianted with data virtualization for use with lists and grids. What is a simple data-bound ListItem or GridCell ends up being a hefty logical + visual object-graph in WPF, and if you don't learn how to virtualize, you app won't perform well on large data sets.
Aside from the flexibility in UI design, there are some technical advantages to WPF:
1.) WPF doesn't rely on GDI objects. Well, I think it uses 2 GDI objects for the instance of the window itself, but that's practically nothing. I've been involved to a certain extent in a very large internal Windows Forms application. The people in our office sometimes run 3 or 4 instances of it simultaneously. The problem is that they frequently run into the 10,000 GDI object limit inherent to Windows 2000, XP and Vista. When that happens the entire OS becomes unresponsive and you'll start to see visual artifacts. The only way to clear it up is to close applications down.
2.) WPF utilizes the GPU. The ability for WPF to off-load some of the UI processing to the GPU is brilliant. I only expect this aspect of it to get better with time. As a former OpenGL programming hobbyist I can appreciate the power that comes from the GPU. I mean, my $100 video card has 112 cores running at 1.5 GHz each (and that's not top of the line by any means). That kind of parallel processing power can put any quad-core CPU to shame.
However, WPF is still pretty new. It won't run on Windows 2000. And in fact, a WPF application can be slow to start up after a fresh reboot. I talk about all of this on my blog: http://blog.bucketsoft.com/2009/05/wpf-is-like-fat-super-hero.html
This seems to have become my favourite thread.
I'm 7 months into using WPF on what has now become a core system for my customer, and I'd like to share some more thoughts with you about the experience of learning and using WPF as a line of business presentation platform.
In general, the comments I made above still hold... the design time support for WPF isn't here yet. If you're in a big rush to get a rich-client application out of the door, go with Winforms. Period. Microsoft aren't in any hurry to discontinue the GDI / winforms platform, so you can count on good support for a fair time into the future.
WPF is not easy to master, but that shouldn't be where you leave your descision about whether or not to invest your time and energy into learning WPF. Despite it's present lack of maturity, WPF is built around some useful, modern concepts.
In WPF, for example, your investment in well-written business objects with sound validating logic is a solid investment. Unlike winforms, WPF's data binding is briming with features that allow interface controls to react to invalid user input without writing GUI code to detect those errors. This is valuable.
The styling and templating capabilities in WPF have proven to be valuable too. Despite the common misconception that the only use for styling and templating is to create on-screen eye-candy, the truth is that these features significantly simplify the coding of a user interface which gives rich feedback - like buttons that disable/enable themselves base on the state of the underlying business logic layer, or tooltips which intelligently find their text based on the state of the object under the cursor, etc.
These all add up to incredibly valuable features for "nothing fancy" business applications, simply because they make it easy to keep the interface congruent with the underlying data.
In a nutshell:
...its a seemingly subtle difference, but it makes a huge difference in your ability to re-use code... which begs the question: "Is the Winforms vs WPF question actually an investment decision?"
For the last 3 1/2 years I've been doing Winforms development (at 2 companies). Both applications were used extensively and ended up having GDI problems. Large Winforms apps will eventually run out of GDI resources - causing the end user to have to reboot.
A quote from an earlier post from Mark:
- In Winforms you design your user interface, then write code to drive that user interface, which generally also includes code to drive your data objects.
- In Wpf you invest in the business layer that drives your data objects, then design an interface that listens to your data objects.
I would argue that this is more of a design choice, rather than whether or not you are using Winforms or WPF. However, I can appreciate that certain technologies might be better suited for a particular approach.
If you don't have WPF expertise and you don't want to invest in it :)
I'd use Winforms for quick proof of concept stuff, because, while it's terrible for real applications, it is very good for "Visual Basic 6.0" - style rapid prototyping.
So, here an example:
If I need to trace through multiple steps of a process (like downloading something, calculating / converting, creating intelligent ouput) and making everything reproducible, I usually make a quick Form, with a ListBox and a few buttons, done.
Since I'm a REAL developer, the logic will already be in classes other than the view anyway, so this is a fine place to start.