tags:

views:

1693

answers:

10

We have a largish MFC app that is our main product. This app is being actively developed and there are no plans to stop development. I am new to windows development, but I get the impression that MFC is dead and all the new growth and enhancements are in .net. Is this view accurate? What criteria should we consider when deciding if we should convert this application to .net.

Here I'm asking why.

I have asked the how question here

+8  A: 

The short-and-sweet: Decide as late as possible.

What is driving your need to move now? This sounds like a commercial app, so what is making you want to spend capital on rebuilding your app on a different platform? Do you think MFC is somehow at end-of-line? Would going .NET make your app more sell-able?

One good reason, for example, is if there is a larger time to redevelop the app versus the time left on disappearing "MFC talent".

Also, if this is a large app, consider phasing rebuilding the app (or building in new functionality) where .NET would bring tangible benefits.

alphadogg
+6  A: 

I definitely don't think MFC is dead by any stretch. It's really hard to pronounce a framework that runs a substantial portion of all Windows applications as dead :).

What I would consider though is the ease of hiring new employees down the road. .Net is certainly more popular with newer devs and MFC is definitely losing ground. 5 years from now, it may be much easier to hire a .Net dev vs. a MFC dev. That's the kind of factors I would consider when deciding to switch from MFC -> .Net

JaredPar
+10  A: 

MFC is still officially supported by Microsoft and I see that it will still ship with Visual Studio 2010 (with a new version probably). So there's no support reason to ditch it. It's definitely not hip and probably not growing (ie it's in maintenance rather than growth mode).

That being said, a complete rewrite is usually a mistake. So don't do it unless you have to (and nothing you've said has suggested you have to).

cletus
That's a great article! 10 years old but ageless. Thanks for providing this link, it again reminded me to be very very careful with decisions about a total rewrite of an application.
Slauma
Yes, really a good article. It helps me ponder my pro-novelty side.
Stephane Rolland
+4  A: 

If you have the ability to make the choice, I would most certainly migrate to WPF/C#.

Once you get over an initial learning curve of WPF/C#, the productivity gains are amazing:

  • Not having to deal with memory management alone is huge (C# vs C++)
  • Stuff that is complicated to do in MFC is dead simple in WPF (For example, creating resizeable dialogs)
  • WPF adds very powerful new features like databinding.

Microsoft has gone to great lengths to give developers ways to use existing C++ code in WPF/C# applications so the real answer is to migrate your code base one piece at a time. With proper design and planning, you'd be able to re-use a large part of your existing code base.

From a business perspective, it's just going to get more and more difficult to find developers who want to work on MFC. As a result, you'll probably wind up paying premiums on salaries. On top of that, do you really want to only be able to attract the type of developer who is content working on legacy technology and not learning or working with newer stuff?

17 of 26
Memory management isn't such an issue when you use standard containers and smart pointers. I wrote my own base class for resizeable dialogs, 260 lines long, and now I never worry about it again.
Mark Ransom
+1  A: 

MFC and .Net both wrap the Windows API. You can get to everything (and more, since you can call the API directly) from MFC than you can from .Net. MFC and C++ are still a perfectly viable Microsoft platform. MFC has been extended for the new Vista controls and is the only place you can get a Ribbon for free. Visual C++ 10 is going to get a lot of enhancements too.

It is true that productivity is much higher in .Net. But you only stand to benefit much from a productivity boost if you have a need to write a lot of new code. If there is nothing wrong with your current application, why rewrite? Using MFC and C++ does not prevent you from making incremental enhancements for years down the road.

The interoperability story between Visual C++/MFC and Windows Forms is pretty good. If you are going to be delivering a lot of new functionality you can very comfortably do it in Windows Forms or WPF plus C# and fairly seamlessly integrate with your existing MFC app.

Aidan Ryan
A: 

MFC is awesome if you know how to use it. DotNet is a result of many programmers not know what the heck they were doing. Native MFC developers who know what they are doing will smoke a DotNet application every time. MFC rules. Thanks Microsoft for listening to the huge base of MFC native programmers. We are the silent majority.

NativeManMFC
A: 

Years ago I chose to stick with MFC for the exact same reason as the OP is considering: I was tired of being jerked around by new scripting languages and frameworks that go our of style. I stuck with learning C++, an ISO standard, and MFC, a C++ wrapper for the Win32 API. Besides, who wants an extra layer of indirection that C+ and .NET force upon you and all the instability and coding insecurity that that entails? Of course, to make that choice, you have to have a pretty big set on you since not going with the flow can have serious economic consequences. But hey, life is short...

I agree with NativeManMFC, MFC is awesome.

rt8277
A: 

Yeah ryt, rt. Have you ever used .NET? I dont think so. Pplz are always afraid of newer technologies, they are afraid to loose their pretty hungurian notaions (makes me SICK!) and using MFCs. Moreover have you ever heard of Managed codes which brings Code and Type safety? I think not. .NET isnt somethng that force an extra layer out of nothing, it does for you to write code in complete safe environment.

Dnt say somethning you dont know.

herbalPizza
A: 

Its not always that people are afraid of newer technologies, its sometimes that they are sick of learning them for small gains. Yes, tech always moves on and you have to move with it as a techy but what royally irritates me is spending a great deal of time learning something new, just so I can implement the same things. Or just spending most of my time learning something new. Its productivity that counts not learning how to be productive.

The other issue with .NET is if you develop on many platforms. C++ is a widely adopted language. .NET is really a microsoft thing. I say really as theres mono but come on.

Id love a world that picked one language and went with it, with different libs and abstraction for different levels and platforms...

ebob
A: 

All OSes including Windows are developed in C/C++ because it compiles to machine code. So Windows API and MFC will be around for the foreseeable future unless they figured out how to write an OS all in C#. Nowdays many clients demand visual and graphics rich GUIs and if your apps didn't look cool it simply won't sell. Thats where .NET framework comes in. Designing custom controls animation on WPF (rendered with DirectX) is so simple that event an noobie can do it. I would imagine it would have taken 10 times more code to accomplish the same thing. On PC C++/MFC is definitely being push into niche area where performance and portablitiy is important like games for example.

Potato