views:

83

answers:

2

Is there a practical way for us to slowly evolve a WinForms application to WPF without creating a support nightmare for ourselves with strange interop scenarios?

Background info:

We have a large battleship gray WinForms application that is heavily used by an internal group of about 60-75 users. We're starting to run into places where we could see some benefit from having the app in WPF, but it's not enough to justify a large project to completely re-write it. All of the screens in the app are self contained WinForms user controls and the WinForms app is just a shell that handles menuing, opening/closing forms, provides some shared helper methods, etc...

Thus far, the best idea we've had is to convert the shell application to WPF and then host the WinForms user controls inside it. We thought that we could then convert the user controls over time, tieing those changes to initiatives that have enough business value to support the additional work. I'm concerned about how well the interop works and how it will impact performance. I'm also concerned about how we transition to a new look for the app. It would seem odd to make the shell app look snazzy and then have old battleship gray user controls hosted inside it and it also seems odd to create the shell app in WPF and make it look just like it did in WinForms.

If one of the Caliburn, Prism, or another similar framework would ease the transition, we'd be open to exploring those options as well.

+3  A: 

We were in a similar situation and chose the following path: At the beginning we started to host a few WPF windows in the application shell (still WinForms). Of course there was some visible difference but we reduced the difference deliberately by toning down the new windows. We figured that by the time we would convert the remaining windows/controls it will be easier to "upgrade" to a more vivid experience since the UI will be entirely WPF and we can involve a graphical designer to work their magic based on XAML.

We have now reached the point where the majority of the windows are WPF. We have started the process of converting the WinForms shell app into a WPF based shell application hosting the remaining WinForms. We sill have sort of dull colors but users have started to notice the difference and although it is small our users still like the incremental positive change. Not too long and we will retire the last WinForm. That will be the point when we let our graphical designers off the leash!

As to performance: I can certainly not make a general statement as it heavily depends on your particular controls/windows. In our product (several hundred windows) we haven't found any significant performance issue related to the mix of WPF and WinForms.

We didn't look into any of the frameworks, so I'm afraid I cannot comment on those.

John
+1 This describes my own experiences very well. Also, here is an interesting PDC session about how Visual Studio 2010 was implemented using NET Framework 4 interop: http://microsoftpdc.com/2009/CL09
Ray Burns
I'm not sure there is a "right" answer to this, but I think this is the approach that we're most likely to end up taking.
Paul G
+2  A: 

Great question, at present most of the work in WPF deals with converting old WinForms application to WPF. From my experience best case scenario is to build the application from scratch based on old application/requirements. Fortunately I have been part of a project where we have re-written the application from scratch and I am sure that it took less time/investment then mixing the two.

I personally feel that it would have created a mess if we had tried mixing the two. Another point is that it will be tough to design the mixed application efficiently.

In my current project (which is a huge project running from past 10 years) we are converting the application module by module basis. Fortunately for us our application consists of various smaller applications, so converting them one by one is easier. In your case I would say that you identify the areas which can be totally converted to WPF and start building them in WPF, as suggested here -

Windows Forms – WPF Interoperability FAQ: http://windowsclient.net/learn/integration.aspx

I would also suggest to use some tools for converting the windows forms to XAML(WPF); that will surely help you in saving some time.

Windows Forms to WPF converter: http://wf2wpf.codeplex.com/

Windows Forms to XAML Converter: http://www.ingeniumsoft.com/Products/WinForm2XAML/tabid/63/language/en-US/Default.aspx

Windows Forms to Windows Presentation Foundation Converter: http://www.spiderwan.com/spiderwan/ConvertWinFormToWPF/WinFormToWPF.aspx

akjoshi
I generally prefer the incremental conversion approach described by John but agree there are times where it makes sense to rewrite from the original requirements. However I strongly disagree that Paul G look at the Windows Forms to WPF conversion tools: Those who use such tools invariably end up with an application that is even harder to maintain than the Winforms app was. Properly done, WPF applications are far simpler and easier to maintain than the equivalent Winforms. The time spent creating quality view models and XAML will repay itself tenfold, especially when doing a rewrite.
Ray Burns
Point taken, designing view models and XAML yourself will be always better. I just wanted to let Paul know of available options(for saving time obviously).
akjoshi