Migrating from WinForms to WPF... was it worth it?

Question

I also have a desktop application in WinForms that is a middling size (a couple dozen major forms backed by 46 tables in the database). I'm thinking about rewriting the UI in WPF, but before I go there I was curious if there were any war stories about doing such a conversion.

I use LLBLGen to generate my low level data access objects, and I have a business logic layer above that. The forms are databound to the business logic objects, although the main form uses caching objects to minimize round trips on the more common navigation routes. The UI never speaks directly to the database: always through the UI -> business logic -> low level -> datastore path.

One control that I use heavily is the TreeView, which acts as a visual guide and short range navigation tool. The tree has been heavily customized with icons, highlight colors and it is the control I worry most about porting.

Does anyone have a story that might convince me to go ahead and convert (or conversely, wait until Microsoft is closer to pulling the rug out from under WinForms)?

EDIT: I was asked in a comment what motivation for conversion I have. I have some concern about future proofing: I have 500,000 lines of code that were originally ASP/VBScript. We have been porting the functionality over time to ASP.NET/C#, but only as we make changes to the code. The upside is we have kept costs minimized, the downside is half the code remains ASP/VBScript. I'm concerned about a similar situation arising with WinForms applications.

Am I worried today about WinForms going away? Not even close to it... but the application moving from ASP/VBScript -> ASP.NET/C# has 9 years of history behind it, and probably won't be replaced this decade (instead, simply it will evolve). The desktop application is likewise a long term project with years of history.

Answer 1

For me, the WinForms vs. WPF decision is a simple one - if normal people are going to use it, the user interface can make the difference between a winner and a loser.

It is definitely a steep learning curve. But I have NEVER gotten done with a nice looking WPF application and said "Man, I should have used WinForms".

I'd say invest in the effort to make your UI better whenever possible for your customers, so yes to WPF if that's the case.

Answer 2

WPF has a ridiculously large learning curve. It will most likely require you to rewrite a lot more than you think for just changing the UI. Also, a lot of features that would make WPF nicer to use just aren't implemented or included in WPF yet. Unlike routeNpingme, I have written nice looking WPF applications and have said, "What a waste of time, I should have used WinForms and completed in 70% less time".

EDIT: Also, unless Microsoft figures out a way to make WPF easier to learn, I don't see it catching on to the masses at all. WPF can do some very cool things, but a little effort to make it easy to understand instead of throwing stuff over the wall would have gone a long ways. It would not surprise me in the slightest to see Microsoft drop WPF for something easier to work with in the not too distant future. So don't go changing your WinForms application just for the sake of changing it.

Answer 3

Porting is a tough decision. So just some thoughts to help you decide.

WinForms is OK while you work by the rules and keep everything drawn as is. But even redrawing a border on some controls may require complex and precise work and skill, as you already know from tree customization. The same tasks can be done in a very elegant way in WPF.

Also, the data-binding in WPF saves me a lot of time. In the long term, you end up thinking about data-binding scenarios that could not be remotely possible in WinForms without special-case coding.

I do not even consider WinForms for new development -- there is no excuse for customization costs.

Answer 4

WPF is great. It is particularly good for extending controls like TreeView with customisations. You can add a string as an item in a TreeControl. You can also add a small panel containing an image and some text in various fonts and colours. Or you can add buttons, or anything you like. It has a completely general composability system. Same goes for ListBox, ComboBox, Button, etc. All their content or child items can be as simple as a string or as complex as a multipage document viewer with zoom buttons (if you want).

But the only way to find out is to try porting one of your forms. It shouldn't be too hard to make a WPF Window open from within your existing app. I started using WPF by making new GUI panels that were hosted inside a C++ Win32 application. Eventually it was so obvious that WPF was the way to go that we switched it around and made the outer shell WPF, with some ancient dialog boxes still implemented by the old C++ code where we couldn't be bothered to rewrite them (probably exactly what will happen with Visual Studio 2010).

Answer 5

Pros:

• Ridiculously easy data-binding (most of the time)
• Ridiculously easy customization of look and feel

Cons:

• Very steep learning curve
• Some obvious bugs or issues. Similar to .NET 1.0 WinForms
• Little or no tool support

In my opinion WPF will definitely replace WinForms at some point. However right now the tools are the main thing keeping it back. I disagree with Dunk that Microsoft will drop it for something else. Change it yes, but I think it's here to stay.

Should you change your app to use WPF now? No. Feel free to learn WPF but if your app works fine currently, then WPF won't give you anything extra. It just makes doing what is possible in WinForms much easier.

Answer 6

I have started introducing WPF elements within my WinForms application and so far have had a lot of success.

The application's main component is a grid control and I haven't yet found the text rendering of WPF sharp enough to present a table of important textual data.

But the application has several additional panels, and the majority of these are implemented using WPF. So, I'm going for a hybrid of WinForms and WPF via the ElementHost control.

I have found the flexibility of WPF to allow for a much more attractive and usable UI, and my users seem very happy with it. In my case, it's also been politically easier to introduce WPF one panel at a time.

Answer 7

I'm in the same boat (60 table business application based on LLBLGen) so I'm curious if you made a decision and if so what your results were?

One of the main motivating factors for me in considering the port is the ability to turn my client-side application into a web application via XBAP--is that something you've considered?