My company has developed a long standing product using MFC in Visual C++ as the defacto standard for UI development. Our codebase contains ALOT of legacy/archaic code which must be kept operational. Some of this code is older than me (originally written in the late 70s) and some members of our team are still on Visual Studio 6.
However, a conclusion has thankfully been reached internally that our product is looking somewhat antiquated compared to our competitors’, and that something needs to be done.
I am currently working on a new area of the UI which is quite separate from the rest of the product. I have therefore been given the chance to try out ‘new’ technology stacks as a sort of proving ground before the long process of moving over the rest of the UI begins.
I have been using C# with Windows Forms and the .net framework for a while in my spare time and enjoy it, but am somewhat worried about the headaches caused by interop. While this particular branch of the UI won’t require much interop with the legacy C++ codebase, I can forsee this becoming an issue in the future.
The alternative is just to continue with MFC, but try and take advantage of the new feature pack that shipped with VS2008. This I guess is the easiest option, but I worry about longevity and not taking advantage of the goodness that is .net…
So, which do I pick? We’re a small team so my recommendation will quite probably be accepted as a future direction for our development – I want to get it right.
Is MFC dead? Is C#/Winforms the way forward? Is there anything else I’m totally missing? Help greatly appreciated!
I’m a developer on an app that has a ton of legacy MFC code, and we have all of your same concerns. A big driver for our strategy was to eliminate as much risk and uncertainty as we could, which meant avoiding The Big Rewrite. As we all know, TBR fails most of the time. So we chose an incremental approach that allows us to preserve modules that won’t be changing in the current release, writing new features managed, andporting features that are getting enhancements to managed.
You can do this several ways:
Host WPF content on your MFC views (see here)
For MFC MDI apps, create a new WinForms framework and host your MFC MDI views (see here)
Host WinForms user controls in MFC Dialogs and Views (see here)
The problem with adopting WPF (option 1) is that it will require you to rewrite all of your UI at once, otherwise it’ll look pretty schizophrenic.
The second approach looks viable but very complicated.
The third approach is the one we selected and it’s been working very well. It allows you to selectively refresh areas of your app while maintaining overall consistency and not touching things that aren’t broken.
The Visual C++ 2008 Feature Pack looks interesting, I haven’t played with it though. Seems like it might help with your issue of outdated look. If the ‘ribbon’ would be too jarring for your users you could look at third-party MFC and/or WinForms control vendors.
My overall recommendation is that interop + incremental change is definitely preferable to sweeping changes.
After reading your follow-up, I can definitely confirm that the productivity gains of the framework vastly outweigh the investment in learning it. Nobody on our team had used C# at the start of this effort and now we all prefer it.