What are some techniques for migrating a large MFC application to WPF/.NET?
I am currently working on a very large legacy MFC MDI application. It has a large number of UI elements - dockable toolbars, custom tree controls, context menus, etc. It is an image processing application so the main views render themselves using DirectX and OpenGL. The product is about 10 years old and one of the priorities here is to update the look and feel of it.
Knowing that Microsoft has done a good job of providing interoperability between C++/MFC and .NET I thought it would make sense to migrate the code base incrementally. What I'm struggling with now is where to start.
One approach is to rip out the MFC framework with WPF and reuse as much of the C++ code as we can. This will let us maximize the benefits of the WPF architecture but will mean a long development period until we're fully functional again.
Another approach is to replace MFC controls one at a time with their WPF counterparts. This will allow us to work incrementally. My concern with this approach is that it means there will be an awful lot of connection points between managed and unmanaged code and I'm not sure where to start with replacing things like the main menu and toolbars.
Or is there another option here I'm not seeing?
Any suggestions or links to information on this topic would be appreciated.
Update: DavidK raised some excellent questions so I'm adding the motivations behind this.
1) Future development of the product
This product is still being actively developed with new features getting added on a regular basis. I thought that it would make a lot of sense to try and slowly migrate towards C#/WPF. In my limited experience with C#/WPF I found the productivity gains to be amazing over working in C++/MFC.
The other big thing we're getting with WPF is the ability to take advantage of multi-head systems. MFC applications are limited to a single top level frame, making it very difficult to leverage multiple monitors.
2) Employee retention and recruitment
It's getting harder and harder to find developers who are willing to work on MFC. It's also important for the career development of the current developers to get exposure to newer technologies.
Answer
Revisiting this because I have successfully replaced our top level MFC UI (the main frame, windows, and toolbars) with WPF.
As it turns out, our core drawing code merely needs to be handed an HWND to render into. This made it really easy to reuse the bulk of our existing C++ codebase.
Here's a quick rundown on the key pieces of the approach I took:
- Used the .NET HwndHost class to host an HWND for the C++ drawing code to render into
- Created C++/CLI wrappers for any native C++ code that needed to be exposed to the WPF/C# UI code
- Left most of the MFC dialogs as-is in the native C++ code. This minimizes the amount of work needed to finish the UI. The MFC dialogs can be migrated to WPF over time.
As a side note, we're using SandDock and SandRibbon from Divelements and have been very happy with them so far.