WPF or WinForms for internal tools?

Question

At my company we develop a number of tools for internal that range from simple utilities to full-blown editors. The priorities for these tools are stability, usability, and turn-around time (meaning how quickly new features can be added).

We've been using WinForms up until now but there's a couple of new tools on the drawing board and I'm weighing up whether we should continue with WinForms or move to WPF. As we control the environment we don't have to worry about .NET versions etc (though we do have to run on XP for the time being).

I'm familiar with the graphical benefits offered by WPF (vector-based, hardware accelerated, skin-ability) but I'm wondering if there are any other aspects of WPF that make a compelling argument for its use over WinForms.

Thanks,

Answer 1

I would move over to WPF for new applications, because it's just nicer in general to work with and, as they say, "The Future."

There's nothing wrong with WinForms though, so if you want to stick with that, there shouldn't be any problems.

Answer 2

I agree with Alex - move over to WPF. One possible limitation is that WPF only works on XPSP2 and later, though.

One advantage of WPF over WinForms is that WPF's data binding is much more powerful than WinForms. It makes putting data-bound UIs together very easy.

Answer 3

I like a lot of the architechtual changes provided by WPF. The updated DataBinding model by itself is worth making the change for, IMO. However, I would weigh that against any potential overhead involved in the group maintaining the tools getting up to speed with WPF.

Answer 4

Don't underestimate the learning curve. WPF can be really great to work with, and it can be a nightmare. I've seen WinForms only developers more helpless with WPF then with ASP.NET (even with very little knowledge of web development). While most developers were able to just start working with WinForms and ASP.NET without reading any books, and were productive to some level, this seems to be impossible with WPF.

And don't forget about third-party components. Yes, there are even new players in the market, and years after .NET 3.0 e. g. SoftwareFX finally managed to release their charting solution for WPF (just as an example), but the component market for WPF is still significantly smaller (commercial as well as open source), and often WPF components are still less powerfull than their WinForms counterparts.

I agree that the architecture, e. g. the data binding concept, is great, if you follow a pattern like MVVM, however there is very little documentation in MSDN on best practice e. g. about MVVM, so you will have to point your team to articles on the web and books etc. yourself.

And data binding is already very powerful and actually very similar in WinForms 2.0. It just looks like few people know about and use it to its full potential. (Maybe they only tried it in 1.1 and thought that it was too complicated...)

Answer 5

I would have the use of WPF dependant on the size and number of projects. The more work you have ahead the more sense it makes to leverage the power of WPF. For CRUD applications, you will not gain much in terms of functionality from WPF besides some eye candy. Where you will win is in medium term productivity as WPF follows a clean approach and not one that has already evolved over and over the years and is highly patched, even though very well dressed, like Windows Forms. Laying out screens in XML does have its benefits.

For quick little tools, however, I would stick to Windows Forms until WPF proficiency is attained, unless one of the purposes is the referred proficiency itself.

Answer 6

Pick a small project to do in WPF and be prepared to refactor the hell out of it as you learn what WPF can do and how to use it properly. Treat the project as "training" because it'll take a while to get up to speed with WPF. Persevere though, because it's worth it.

Answer 7

If your company is considering a strategic decision to move in the future to WPF then starting with internal tools might be a good place. If you don't have any such plans then taking on the very major task of understanding WPF simply isn't worth it. And if you think that perhaps someone should be looking at whether to make a strategic move to WPF and this would be a good place to start, make sure it's someone with enough clout to get listened to.