3

I have a chance to start porting a legacy application written in C++/Powerbuilder to c#. We have a feature this sprint that launches an independent dialog and I just went through the exercise of creating a CCW dll for my managed implementation of this feature, to be called from C++. I decided to use WPF for the views in my managed DLL. So far so good, as I am able to inter operate with my managed DLl, including launching the WPF window from a sample MFC app.

There are several reasons motivating this strategy:

  1. I have a bunch of re-usable manage DLLs that came to being from a recent redesign of a 10 year old legacy app.
  2. I am fairly experienced in C# as compared to C++ where i find myself constantly battling with language syntax and intellisense. FWIW, our company could do better in investing in some tooling although it will not really change my dislike for the C++ syntax, header files and inconsistencies......of approach.
  3. For desktop apps atleast for the kind of applications we develop, I think C# is the way to go. 4.There are future plans to re-write the app, and I do not want to repeat myself, hence the temptation to start designing things right, where I can, at this stage.
  4. I do not have alot of C++ help.

However, I have some concerns and questions:

  1. Is this piecemeal approach the way to go?

  2. From a performance perspective is, should I be interoperating with Winforms instead of WPF? Application will be hosting a GIS so performance is key, although we have just developed another WPF application that host ThinkGeo's MapSuite and it performs quite well. Main difference is the legacy app is alot more GIS intensive that its WPF cousin.

  3. WIth the latest rumours about the fate of WPF/Silverlight, should I even be considering WPF? What are the alternatives anyway for desktop apps, if WPF/Silverlight was to die?

3.What are the gotchas waiting for me?

Any thoughts and/or advice on this will be great. I will be consulting with my manager on this but wanted to get some of your thoughts and experiences first. TiA.

Klaus

EDIT:

Sorry but application is 10 year old and not 25 year old as originally stated. Little mix up there.

Klaus Nji
  • 18,107
  • 29
  • 105
  • 185
  • If your application has any serious scale, you likely won't finish doing this as a hand migration. It has 25 years of development in it, surely it is fairly large. Surely you're not going to recode all that by hand, and expect to preserve all of its properties? You might find this discussion useful: http://stackoverflow.com/q/3455456/120163 – Ira Baxter Jul 01 '11 at 19:31
  • WPF & Silverlight are nice alternatives to PB. Expect development to take about 4x what it takes in PB and that also assumes you are flexible about the GUI. It's still hard to duplicate the datawindow, I use Telerik grids but nowhere near the flexibility as a datawindow. – Rich Bianco Jul 30 '11 at 17:04

1 Answers1

1

I don't see a better approach than the piecemeal one. And you can always use C++/CLI (aka managed C++) to bridge any difficult gaps.

I'm a big fan of WPF/Silverlight so I would definitely suggest it above Winforms, which is good but a much older looking technology. Custom controls and data binding have made things a lot easier for long term development in the WPF world.

The rumors of WPF dying off are just plain nonsense. Yes, Microsoft reduced the size of the WPF team -- mainly because WPF has become mature and stable. They want to put more resources into the browser areas for strategic reasons; not sure why anyone would equate that to them killing WPF.

I've had great success in using WPF to wrapper or interface with legacy code written in C++. The main "gotcha" I've run into is when you have layers of managed and unmanaged code, it can get a bit tricky and hard to debug. You may want to consider writing a custom assembly loader callback so you can see more about what fails to load and why, especially if you have a legacy app loading a C++ DLL that ends up running managed code.

Ed Bayiates
  • 11,060
  • 4
  • 43
  • 62
  • Thanks for the advice. I just ran into my first debugging 'gotcha' yesterday in trying to create a simple wrapper for my managed class. With some advise, thanks to StackOverflow, I was able to attach a debugger to my managed DLL. But, yes, that was some challenge. Taking the piecemeal approach makes sense. My approach is to implementing new application extensions in WPF. – Klaus Nji Jul 06 '11 at 13:46