Develop Reference

C# vs F# for programmatic WPF GUIs

I'm trying to decide where to draw the line on the use of F# and C# in enterprise software development. F# for mathematical code is a no-brainer. I like F# for GUI work even though it lacks GUI designer support but, of course, there is more resource availability of C# GUI people in industry. However, I am not too familiar with C#+XAML GUI development so I'm concerned about introducing bias.
In the case of one client, they have dozens of similar GUIs that are quite static (changed yearly) and a few other GUIs that are very dynamic (e.g. business rules engines). They already have F# code live and are already investing in F# training so skills availability isn't an issue. My impression is that C#+XAML let you build static GUIs (a few sliders, a few text boxes etc.) easily but I cannot see how the GUI designer would help with programmatic GUIs like a business rules engine. Am I right in thinking that maintaining a battery of mostly-static GUIs (e.g. adding a new field to 100 separate GUIs) will require manual labor? Also, am I right in thinking that the GUI designer is of little use in the context of heavily programmatic GUIs so something like a business rules engine would be written primarily in C#+XAML with little use of the GUI designer?

I've done a good amount of GUI and non-GUI programming in C# and F#, in work and play, heavy programmatic and static... and I believe your stated impression is accurate and practical. (note that I am more familiar with WinForms than with WPF, but I don't think the differences matter here).
My impression is that C#+XAML let you build static GUIs (a few
sliders, a few text boxes etc.) easily but I cannot see how the GUI
designer would help with programmatic GUIs like a business rules
engine.
This is absolutely my experience. For mostly static GUIs, I prefer using the WinForms designer with C#. The tooling combo is great for these scenarios and is more productive than hand-coding the GUI with F# and no designer (now, if there were F# support with the designer, I would have no hesitation preferring that). I'm Only Resting is an example where I have preferred C# with the WinForms designer over pure F#.
And for heavy programmatic GUIs, I believe it is best to avoid the designer altogether, rather than to attempt to go half designer half programmatic (it gets real messy, real quick). So in these cases I definitely prefer hand-coding the GUIs in F#, since everyone knows F# is the more expressive language ;) FsEye is an example where I have preferred pure F# over C# with the WinForms designer.
Am I right in thinking that maintaining a battery of mostly-static
GUIs (e.g. adding a new field to 100 separate GUIs) will require
manual labor?
Probably. I don't believe there is really any ready solution for this problem since it is really quite a large one. But there might be some best practices out there for building a custom solution right for your suite of software.
Also, am I right in thinking that the GUI designer is of little use in
the context of heavily programmatic GUIs so something like a business
rules engine would be written primarily in C#+XAML with little use of
the GUI designer?
Yes, like I said early, it is my belief that you ought not try to mix the GUI designer with heavy programmatic GUI programming.

I recently built a directed graph visualization application using purely F# and WPF.
For the 'programmatic' GUI parts, I essentially built WPF custom controls that I could operate with data binding and MVVM.
For the static parts I used XAML with out-of-the-box and custom WPF controls.
I used the FSharpX WPF Type Provider extensively for MVVM binding.
And this 'book' helped me quite a bit to get started. http://wpffsharp.codeplex.com/
Some things don't come naturally with F# and WPF but in almost all cases a reasonably elegant solution was found. Some WPF data binding strings did become large and unwieldy.

I don't know how exactly to answer the question as it's somewhat hard to get hold to so I just give you my 0.05$:
If you do WPF with a good MVVM (there are even Rx-Versions that are influenced by FP-land) you won't write code-behind (or almost none) - and with WPF type-providers and all the other great stuff that's around you can already write WPF-F# applications without any problem (even designer support is no problem - just use BLEND if you can - if not you can still seperate the GUI into a dumb C#-lib.)
so why don't I write most GUIs in 100% F# then?
Well to be honest... it's the lack of refactoring and tools like ReSharper - it's just frustrating that I cannot search for F#-symbols or types because there is no freaking support in VS/R#er right now.
It's strange but writting MVVM code where you have to create much trivial code for your Viewmodels seems to be easier to do in C# with the right tools right now (for example: I can configure R#er to insert me all the code for public probertys with private/public setters and INotifyPropertyChanged based on internal fields by just hitting - and choosing the right option - this will generate lot's of very dumb code but it's much faster that you could do in F#)

As you have pointed out, F# is a much scarcer skill among programmers in the general IT industry, whereas every man and his dog knows C# (or for that matter Java, C/C++ which easily translate across).
Thus from a purely managerial point of view it likely makes more sense to go with C#+XAML over F# because of a number of factors:
Programmer's salaries - hiring an F# guru adds quite a bit to the salary budget
Development time - this could be argued either way see 1 for a good comparison
Corporate risk - usage of F# greatly increases the risk factor in each of the categories:
Programmer leaves company and takes intellectual property with them
Programmer leaves company and company cannot hire a replacement => project misses deadline
Company does not have adequate metrics available to gauge the time required for the project
Language becomes depracated and code has to be ported (not as great a concern but still higher-risk than C#)
Etc. etc.
However, from an engineering perspective, F# (perhaps with an add-on library for visualisations) is able to simply generate a powerful GUI. C#, though, also has this capability - you can generate your entire GUI without using XAML programmatically.
As for adding a new item to 100+ GUIs, here I don't see how XAML is a disadvantage at all. If I understand your question correctly, you can use a Data Template which you can update once in XAML and have the change propagate across all your GUIs.
In conclusion I would suggest to you that unless you have a strong reason to use F#, stick with C# as it will reduce risk to your company in the long term.

I see alot of confusing answers and solutions here. F# and C# can be combined in solution. Let C# manage GUI and F# manage packages. Also, XAML vs WinForms is a no brainer. With XAML, There is more than enough room for code behind to do any and everything you need. If you're using WinForms then I do believe you need to retire from it immediately. WPF for example, is far more flexible and extremely powerful with GUI options far above those of WinForms. Not to mention the binding power of XAML. XAML is static but communicates with code behind just well and can communicate to any and all .NET languages. Use F#, use C# together and definitely leave the world of WinForms forever. Here is a little project that I've done. It uses only a combinatin of WPF, Silverlight, WCF, F#, C#, and VB.NET. WinForms wasn't touched and if you look closely you'll see that acheiving this with WinForms would have taken ages. I could have completed this with only one language but swapping helped save time depending on the situation but I only went forward, never backwards. WinForms as well as all other legacy options were ignored and never used.

Looking to ditch Winforms and start using WPF

Windows Forms is pretty old now, and has been superseded by WPF. I've seen a lot of material regarding databinding WPF layouts, using the MVVM pattern for the applications and some cool animations to boot.
I think it's time for me to abandon the Winforms ship and start using WPF. Once I finish this last freelance project I'll start using WPF exclusively for my Windows Clients.
I have the privilege of having customers with newer machines, so running WPF on their machine won't be a problem. :)
Trying to grab the entirety of WPF is extremely daunting and I feel that if I just dive right in I might keep doing things the Winforms way when in fact WPF has a newer, more succinct way of doing things.
Where do you recommend I start? What are some things you wish you knew before using WPF for production? What book would you recommend that teaches you about WPF (has to be new! nothing from 2007)?

I've just done the exact same thing. I am in the process of moving some apps to WPF. I've decided not to bite off MVVM just yet, or any VM. I'm just trying to learn the basics of WPF. I have found SO, other internet sites and this book very helpful.
BTW, I'm finding it's much easier than I thought. Takes some getting used to, but I'm already hooked (XAML is very cool). I'm convinced the best to learn is to simply jump in and start doing it.

The main advice I can give is to "forget" what you have learned with winforms. Do not try to apply what you did with winforms to wpf... The architecture is quite different and you risk to fall into traps.
Maybe MVVM is not required at your early stages of learning, but its approach make the WPF coding easier than without. Take a look not so late at the MVVM Light Toolkit. This MVVM framework is really light but provide what is required for a full MVVM framework, and only that.
good luck, and do not hesitate to take a look at Silverlight also. The border between the desktop apps and web apps are as slim as ever.

How I'd start teaching someone WPF today:
Make sure they have a solid grounding in XML. If you don't know how to edit XML documents and diagnose and fix problems in markup, you're not going to be able to make progress with WPF. You especially need to be able to work with XML namespaces and understand namespace prefixes without freaking out.
Create an example application that creates a bunch of text boxes and binds them to the properties of an object that implements change notification. Data binding is the fundamental technology of WPF, as far as I'm concerned. Once you understand binding - and it's not that hard to understand, really - the design of things like dependency properties and styles become a lot easier to grasp.
Add additional object types to the application and demonstrate how data templates and template selection work.
Add styles, particularly styles that use data triggers, to the example application.
Add items controls to the example application and demonstrate how items panels and item container styles work. Maybe take a little journey into the different kinds of panels. Walk through how observable collections and INotifyCollectionChanged work. At this point I might possibly create a piece of the example collection that used an ItemsControl with a Grid as its items panel, so that I could walk through item container generation and attached properties.
Refactor the example application to move styles and data templates into resource dictionaries, to demonstrate how resource dictionaries work.
Walk through the design of dependency properties, tying their design back to the concepts we've already mastered. To show this off, I like to add a modal dialog that contains a font-selection combo box for the entire application.
Add commands (using the RelayCommand pattern) to the back-end objects, to demonstrate how commanding works.
Refactor the example application to use user controls.
Walk through customizing a control template.
I don't know of any WPF tutorial that approaches the problem like this, unfortunately.

What i think is most important:
Databinding, one of the most outstanding features of WPF, takes a while to get used to though.
Commands, not sure if there is something like this in WinForms...
DataTemplates, create large parts of the UI on the fly based on data.
Styling, if you need customized controls.
Also you should probably acquire basic XML knowledge if you don't have that already to be able to write XAML (I wouldn't use the designer in VS).

I would heartily recommend the book WPF Unleashed by Adam Nathan. It's how I learned WPF, and I still reference it regularly now, years later. Great introduction that explains things in a clear order, gradually building up skills.
I echo what was said above - forget much of what you know in WinForms. If you try to think of WPF as a "prettier WinForms" you'll not get the full benefit of the platform. Learning to "let go" a bit and embrace Data Binding (SO much better in WPF), and to embrace the idea that controls don't have speficic visuals, then you will be truly free to use WPF to its fullest.

'WPF in Action' is a great book to read before starting any coding. Its very simple to understand and if you have the patience you can go through the entire book in a day or two. It doesnt have any MVVM stuff so for someone coming from a winforms background its great to start with.
Once you 'get the hang' of WPF concepts you can jump into MVVM. Two great MVVM resources I found when learning all things WPF were
1. Video by Jason dolinger
2. MSDN article by Josh Smith

What's are the best readings to start using WPF instead of WinForms?

Keeping in mind what CannibalSmith once said - "All the answers are saying "WPF is different". That's a huge understatement. You not only have to learn lots of new stuff - you must forget everything you've learned from Forms. It's a completely new way of doing UI."
.. and having many years of experience with visual Windows desktop applications development (VB6, Borland C++ Builder VCL, WinForms) (which is hard to forget), how do I quickly move to developing to say well-formed WPF applications with Visual Studio?
I don't need boozy-woozy graphics to give my app look and feel of a Hollywood blockbuster or a million dollar pyjamas. I always loved tidiness of standard Windows common controls and UI design guidelines, end even more I enjoyed them under Vista Glass Aero Graphite sauce.
I am perfectly satisfied with WinForms but I want to my applications to be built of the most efficient and up-to-date standard technologies and architectured according to the most efficient and flexible patterns of today and tomorrow, leveraging interface-based integration and functionality reuse and to take all advantages of modern hardware and APIs to maximize performance, usability, reliability, maintainability, extensibility, etc.
I very much like the idea of separating view, logic and data, letting a view to take all advantages of the platform (may it run as a web browser applet on a thin client or as a desktop application on a PC with a latest GPU), letting logic be reused, parallelized and seamlessly evolve, storing data in a well structured format in a right place.
But... while moving from VB6 to Borland C++ Builder was very easy (no books/tutorials needed to turn it on and start working) (assuming I already knew C++), moving from BCB to WinForms was the same seamless, it does not seem any obvious to me how to do with WPF.
So how do I best convert myself from a WinForms developer into a right-way thinking and doing WPF developer?

Read this questions:
How to begin WPF development?
Is there a WPF Cheat Sheet outhere?
Learning MVVM for WPF
Learning WPF and MVVM - best approach for learning from scratch
MVVM: Tutorial from start to finish?
Download and work through this Microsoft tutorial: Southridge Hands-on-Lab
Check this videos:
Mike Taulty's series of videos
Jason Dolinger on Model-View-ViewModel
And after that, take a look at StackOverflow questions tagged with both wpf and mvvm

Keep in mind that MVVM seems suited only to single window applications.
I dived into WPF based on inexperience and general recommendations that it would suite better a kiosk project, especially one where the customer has given me photoshop images of all the application screens. Having cool graphics was a requirement for this project and I liked the vague resemblance of WPF with web development.
I found out a few downsides
1) there is no such thing as an official MVVM toolkit. There are a lot of them, all backed by an individual. A shot at a toolkit by Microsoft has been put on the back burner one year ago and there is no VS2010 support.
2) programming a multi windows application, sort of a simple wizard with back and forward, is plain nightmare. I got out of this with a clean design defining a delegate for each UI action and a command for each business action, but still I think it is too much involvement with a framework to be justified, and you cannot show the result of your tests to this customer expecting excitement.
3) You give up the habit of double clicking a button and adding some code. This leaves a nagging feeling of using the IDE against its nature. Basically you use Visual Studio as a text editor and an interface designer, still with a great help from the tool.
The upsides, so far are:
1) defining visual components is very flexible, fast and easy and you can choose between VS and Expression Blend. Animations are simple to create.
2) data binding simplifies the application. You define a DataContext and bindings and do not have to move data from the business logic to the interface yourself, as long as you have a property for everything that must be displayed.
3) You can reduce the amount of business logic in the interface to zero. It is easy to separate the application behaviour from its looks, so you can skin your interface in ten different ways with little effort and test all of your logic without opening a window.
4) you leave a door open to going with Silverlight if they ask you.
My conclusion is that if you have an MDI application in mind you might find yourself in big trouble. You should be aware that, if you choose WPF, you are ploughing ground for future generations rather than getting on a train that will get you there fast and easy. There is no established way to do things, especially those that are not covered by demos.
Toolkits, all things considered, are not so important and each of them will serve you well. In fact a couple supporting classes are enough to start and there are no fancy wizards, it is up to you to follow conventions.
You might even make your own if a few hours, once you understand what is involved in the logic. The downside is that you will have to really understand it well to bend the application your own way.
As I said above, I had to learn a lot just to show a new view when they click a button keeping the code clean. Take the time to see the videos cited elsewere on StackOverflow it will save you time.

if you are looking for books just look at this previous post
What WPF books would you recommend?

Having got into WPF this year, the most important thing for me was learning how to use the Model View View-Model pattern for separating the view from the app logic. As a general rule of thumb if you find you are placing a lot of code in the code behind for your view then you are "doing it wrong".
I found that coming from a WinForms background I was putting in lots of event handlers and doing stuff in my code behind. As I became familiar with MVVM and WPF features I found I was able to remove the bulk of my code behind and replace it with views binding to view-models.
It was articles like this one from Josh Smith that helped get me started on the MVVM path:
http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx
Once you have started to get the hang of displaying data view MVVM bindings, have a look at commands and specifically the ICommand interface. They are the main mechanism by which actions from the user triggers operations to execute. So rather than having a OnClick handler for buttons, you bind the Command property of the button in XAML to a property in your view-model that exposes an ICommand implementation.
My 2c - Donovan

Try this smashing hit.
Windows Presentation Foundation - Unleashed By Adam Nathan
(source: adamnathan.net)

WPF with code only

I've seen a lot of questions about the merits of WPF here, and essentially every answer says it's the bee's knees, but essentially every answer also talks about things like XAML, in many cases graphic designers and Expression Blend etc. My question is, is it worth getting into WPF if you're a solo coder working in C# only?
Specifically, I don't have a graphic designer, nor any great talent in that area myself; I don't use point-and-click tools; I write everything in C#, not XML.
Winforms works fine in those conditions. Is the same true of WPF, or does it turn out that important functions can only be done in XAML, the default settings aren't intended for actual use and you have to have a graphic designer on the team to make things look good, etc., and somebody in my position would be better off to stick to Winforms?

I'm a code person myself, and to be honest, it doesn't matter. Even if you don't know anything about graphic design, you can still use the editor in visual studio to design an UI. The designer features an drag&drop designer as Win Forms does, so that doesn't really pose a problem. Even though I'm a code person, I have no problem with xaml, as it is, in some way, code again. I had problems with the xaml at first as well, but I got used to it, and stuff I had to do in code in Win Forms was quite easy in xaml.
Databinding simply rocks, you don't have to care about getting the data to the UI, you simply have an ObservableCollection<T> or similar, and one Property in the xaml code and everything gets done for you. Want to format the data? Simply add a formatting property to the binding. Want to color the text according to the value? Template Selector class with 15 lines of code, Binding and Template selection in the xaml code of about 10 lines. I'm really growing to love it, and with time (as with any other new technology) you get used to it, and produce good looking stuff.

Short answer: is yes, you can do WPF with code only.
Longer answer: The part about a designer being able to work on the UI and a developer on functionality is really just a side-effect of decoupling functionality from presentation.
What WPF brings to the table in a powerful way is data-binding which enables you to use wider range of design patterns. MVVM has been discussed quite a bit recently.
The various MVVM framework encourage convention over configuration allowing you to write less code to accomplish the same goals.
This decoupling also has the nice side effect of making your application more testable (you don't have to write tests if you don't want to, but at least the option is there).
Moving to WPF from WinForms will most likely be worth it for you for new development. You could in theory keep doing what you've been doing with WinForms (just with new libraries), but it gives you the option to incorporate newer tools into your development as you become more comfortable with technology.
If you haven't seen it already, the BabySmash series by Scott Hanselman is pretty interesting.

IMHO, it is worth going the WPF route if only to ensure that you build these skills. I have toyed with Silverlight which is XAML based and I could transfer much of that knowledge to WPF even though SL is a subset.
And to be honest once you get used to it, most UIs are build just as easily with WPF as with WinForms. And the tooling is quite nice, using SketchFlow for prototyping is useful, and does not require you to have any real artistic skills other than what you have for doing WinForms stuff. I believe going forward, it would only benefit me to be learning more about WPF, and I believe that would be the case for others.

Everything that can be done in XAML can also be done in code due to the fact that XAML is merely a DSL for instantiating and configuring graphs of objects - specifically those in the WPF library (System.Windows). If you're building line of business apps, then there's very little that WPF offers that isn't available at all in WinForms. The key difference is that WPF allows you to do many things much more easily and flexibly, due to its more advanced object model.
I think that WPF is certainly worth learning, but if you want to do it without learning XAML, then I think you'll probably find it more difficult grok.
It's also worth considering that many WPF developers write the XAML by hand (whereas their designer counterparts will be more likely to use Blend in the first instance) partly through necessity (the WPF designer prior to Visual Studio 2010 wasn't very good) and partly because the object model lends itself to a more concise expression in XAML than in C#. XAML is itself quite a small language but the object model it is used to define (the WPF object model) is huge - and that's where the complexity comes from.
If you have no compelling reason to stop using WinForms, then don't. However, if you can push aside your preconceptions about writing code in XML rather than C#, then I think you might be surprised how this different approach to building a UI might clean up your code.

I say WPF can be for you, and if you don't want to go the xaml way and do code only you should go ahead and do that, in xaml certain thing are impossible but it is the preferred way of doing layout, but no one forces you not to do it in code, however if you learn xaml you will produce UI elements faster, then you would in code, so that's something to remember.

this is an old post but...
To my opinion, there are no bounderies when you code by your self in any environment and that always something needs to be discovered. People have created layouts in code for many years in the past, but certain factors moved the community to create graphic and ui tools. But again, nothing lasts for ever and trends change quickly. Also remember the transition from ASP inline coding to layout composition style of ASP.NET and then back to inline with ASP.NET MVC. Was it a step back? Certainly not, because it was supported with other techniques and tools like razor, dynamic language, model binders and more.
So, actually noone can tell you the right way to work as long as you follow basic rules and standards and realise that it's not just code but rather today's code, with all the lambdas, linqs, expressions, anonymous, DLRs etc.
Who knows? Maybe you will be the one to create a new way of expressing and driving content.

Is WPF a good choice for developing line of business user interfaces? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
We're debating whether our future Windows UI development should be WinForms or WPF. How have some of you made this decision? Most of our applications are LOB applications, and I'm not sure I see a clear and overwhelming benefit to WPF for these types of applications. However, my knowledge of WPF is limited. I'm also a little concerned that WPF will be in vogue for another couple years and then Microsoft will get tired of it and push something else on us. I guess one argument against this is the fact that Visual Studio 2010 is a WPF application.
Thanks.

There are a lot of factors to consider here.
Reasons not to choose WPF:
It currently has less support than WinForms for common LOB controls like date pickers, numeric entry widgets, and so on, though this is improving via the WPF Toolkit, in WPF 4 and through third party control vendors.
The tooling isn't fit to kiss the Windows Forms designer's boots. (Though to be fair this is partly because the tooling has to cope with much more sophisticated ways of constructing views. And Blend is definitely getting there.)
A very different mental model to Windows Forms. To get real benefits out of WPF, you need to think in a very different way to what you're used to. So there may be a substantial learning curve -- not just in terms of learning the technology, but in terms of internalising the idioms and patterns (though there are now a lot more community resources around idiomatic WPF than there used to be).
Reasons to choose WPF:
Decent architectural support. WPF (if you do it right) has a decent separation of code and UI built in, making WPF applications much easier to test and to evolve.
Greater flexibility. For example, if you need a simple map display, you can build it in a couple of hours from a ListBox, instead of having to research and purchase a third party component or write a map control from the ground up. Simple data visualisation is a killer feature for WPF.
WinForms is a dead end. It's not going to see any enhancements from Microsoft, and control vendors are already beginning to shift to WPF as the WinForms market saturates.
Most of your WPF experience can be ported to Silverlight, which (a) gives you flexibility to bring your apps to the browser and the phone, and (b) gives you additional confidence that Microsoft won't lose interest -- even if they do get "tired" of WPF, they've shown a very strong commitment to Silverlight.
Personally, if I were starting a Windows desktop app now, I would choose WPF. However, I've already climbed the learning curve. For a team that doesn't have WPF experience, the cost of taking it on must be a greater factor than it is for me.

One thing to bear in mind is Silverlight. Is it possible that you'll want to write your application to be run from a browser in the future, or possibly even from a Windows Phone 7 device? While Silverlight and WPF aren't quite the same, they're extremely similar. This would be my primary "future-proofing" argument in favour of WPF.
Personally I like the composition model of WPF - as well as a declarative way of representing the UI, and a better layout system than WinForms. Not that I'm a UI guy, really.

WPF is a game-changer for me. My company's flagship application is a WinForms program whose UI is build dynamically at runtime from metadata. It was about six months' effort, all told, to get the UI even stable, let alone attractive. There are still some bugs that I haven't been able to fix, largely because UI code is hopelessly and unavoidably intertwined with data-model code. And don't get me started on window handles.
Now that the system's been in production for a year or so, customers are coming to me with requests like, "We'd like to be able to reorder the information on this screen by dragging and dropping," and "Can we get this information to display in a grid on this part of this tab?" and - my favorite - "Can we get spell-check and auto-text?" Those requests go onto a backlog that's getting pretty damn long.
It's taken me a fair amount of time to figure out how to refactor the application's design so that it can support a WPF UI. (Actually, that's a considerable understatement. I've been grappling with this off and on for a year and a half, and I only started getting traction on it once I broke out of the WPF books I was working from and learned MVVM.) Once I did, the results are spectacular.
The code is much simpler. There's much less logic to debug. Everything in the UI is much faster, which is important because the whole reason this is a desktop app in the first place is that we needed a very responsive UI. My program can create thousands of UI controls without my having to worry about window handles. The ease with which I'm able to change the look and feel of the program is jaw-dropping.
(An example: The UI presents DataRows with a variety of templates. Since a given screen can have dozens of rows on it, and the cursor is kind of small, it's useful for the user to be able to tell, at a glance, what row the cursor is in. It took me ten minutes to implement the styles that now make this visual affordance available everywhere in my application. That's less time than it would take me to estimate that feature if I wanted to add it to my WinForms app. Granted, it would have taken a lot longer if it couldn't be done by adding two styles. WPF's is seriously not magic.)
Are there downsides? As Ms. Palin likes to say, you betcha. Browse some of the questions I've asked on SO - the one about how a no-op value converter changed the behavior of data binding is a good one. The entire rub-your-belly-while-patting-your-head approach to debugging bindings is pretty frustrating, especially since it's so easy to have binding errors and not even know it. (I now keep my Output window on the screen at all times just so that if there are any binding errors while I'm testing, the movement of the messages getting logged will catch my eye.) It would be nice to be able to get a real stack trace when your window throws a XamlParseException. Don't start me talking, I could talk all night.
And the tools! Visual Studio's visual tools for building WPF UIs is completely useless to me. I have Blend, and have used it to re-template a control, but in general I find using Blend to be like trying to jog through a swamp full of hubcaps and baling wire. I'm sure it's really awesome if all you know is Blend, but if what you learned first is the WPF object model and XAML, the behavior of Blend is pretty mysterious. The XML editors in Visual Studio and Kaxaml give me a sad, and Resharper's WPF functionality is, let us say, a work in progress. I much, much prefer the tools for WinForms that make it possible for me to smoothly and rapidly build the slow, quirky, and unmaintainable crows' nest of code that I'm coming to loathe.

WPF looks set to replace Winforms, at least on Windows Mobile devices, with future development focused around Silverlight (a WPF spinoff) and XNA.
In an open market, it makes sense to cover WPF if you want to keep yourself attractive to a wider recruitment market.

I've wondered that myself. But the fact that VS2010, like you said, makes a lot of use out of WPF says to me that Microsoft is trying to tell the world that it's not just another MS fad, but it's going to stay around for some time.

I think MS is sending a clear message that WPF and Silverlight are the present and future. The Winforms PM has said as much. Additionally, WPF and Silverlight are expected to converge in the future.
We went through this same dilemma about 6 months ago at my office. We were starting a large LOB app and no one on the team had a lot of experience in WPF or Winforms. That being the case, we couldn't find an overwhelming reason to go with Winforms and we felt that WPF offered us a much cleaner separation of concerns. We decided to go with WPF and use PRISM as the app framework. 6 months on, I think we made the right choice.

Knowing both, I really hope that WPF is the future. Windows Forms has incredible pain points, e.g. regarding Data Binding, and it's pretty much a thin film of .NET on a lot of existing stuff. When I had to debug into classes like BindingSource, it scared the hell out of me. Now, I don't know how the WPF classes look inside, but Microsoft is bound to have learned something between 2001 and 2006.
I love WPF because of
styling
data templates
excellent and first class data binding support
declarative UI set-up
atached properties
...
I can only hope that Microsoft will make more use internally of this UI technology, thereby reducing its weaknesses which have mostly to do with performance. WPF is fairly demanding.
In VS2010 I hope to see designers that will show off the power of the UI (the XML Schema designer in the Beta already looked pretty useful). I would think that an App like MS Word would profit a lot from all the transformation capabilities of WPF.

WPF is a great framework for creating apps. And when you combine it with a good GUI architecture such as MVC, MVP or MVVM it is brilliant at making interesting looking line-of-business apps with more pizazz than your standard WinForms application.
XAML on the other hand is the ugly cousin that comes along with WPF. The main issue with XAML is the tooling. The tools are worse than non-existent, because they make people think that there is a WPF designer like WinForms, when infact most devs I know use the equivalent of notepad to develop their XAML.
The other tooling issue with XAML is the compiler. XAML is only slightly better than magic strings. The compiler can't pick up most mistakes you make in XAML, and some mistakes won't even crash your app. Instead WPF will print an error message to your output and carry on.

Being that they essentially ditched winddows mobile for Windows Phone 7 which will only use WPF and XNA as its main UI layer I would have to say yes. One could even consider this move as an expiriment for the much more widely deployed Windows OS. That and most users love dumbed down eye candy IMHO.

On the question of tooling, I will concede that building WPF and Silverlight Apps in Visual Studio 2008's designer has required quite a bit of expertise to get right. However I hope you'll give a look to the improved designer in Visual Studio 2010 - it has many more features that we hope will make sense to the Windows Forms developer for building business forms, whether in Silverlight or WPF.
Check out these videos:
Data Binding and Forms Tools
Styling Tools
Futures
New Features in Beta 2
And get the Release Candidate here:
The team has a new Blog here
I hope you find this useful info - if you've already tried Visual Studio 2010 I'd love to hear your feedback. Send me mail at mwthomas at microsoft dot com.
Thanks
Mark Wilson-Thomas
Program Manager, WPF & Silverlight Designer, Visual Studio

IMHO, Microsoft gave some clues about it's future path by developing VS 2010 in WPF.
WPF is no more, no less than WinForms. It has a totally different and extensible way of UX design.