Visual C++ port to C# or C++.NET, pros and cons?

So we have been tasked with modernizing an old Visual Studio MFC C++ windows program (with forms, graphing, engineering analysis, etc.), the client wants it moved to .NET technology.

We have an internal question (i.e., client has not specified) as to whether C# or C++ .NET is the proper target for the port.  Pros cons I can think of:

* For C++: depending on the previous design maybe we can cut-and-paste large portions into our C++ .NET target, with less verification.  
* On the other hand, is C# similar enough to C++ where that is almost a cut-and-paste too?
* For C#: is C# more "future proof" than C++; is it more "modern" than C++?  

Any thoughts would be appreciated.  Thanks.
Who is Participating?
drichardsConnect With a Mentor Commented:
Specifically to your questions:

The MFC forms would recompile directly.  As I mentioned, there may be a few minor tweaks if you did not follow MFC message handling function signatures exactly.  You could be a little lax in older versions.  Otherwise, no work required.

As far as the modern look, MFC added some stuff so you can use the newer UI styles (see the link from previous post), but I don't know if that requires just updaing some properties of the controls or do you actually need to change out classes and rewrite code.  I would guess there would be some redesign of the UI here.  Our customers are content to stay with the familiar look, so although we've updated the compiler, we have not had to go for the "new look".

As to the point of ".NET technology", they are basically correct in that .NET is really about managed code.  For an existing app that works and is not undergoing major functionality change, it is questionable whether ".NET technology" makes any sense.  The value of .NET is supposed to be developer productivity, robustness of the app, and possibly some amount of cross-platform capability (Mono project, for instance).  Since your app is already done and debugged, converting to managed code is only overhead.  You could spend the time developing another app or enhancing the one you've got instead.

Some general thoughts:

At the end of the day, the customer pays the bill, so if they believe it is worth paying just to have the same app redone with a different programming language, that's what you do.

Remember, too, that porting code means retesting and debugging all over again.  If you have a good set of tests, it helps a lot.  If any of them are automated UI things, they likely will have to be redone if the UI technology changes.  That needs to be factored into the cost of porting.

I understand your quandary.  It is not a clear-cut decision and there are arguments both ways.  If it is strictly an internal decision, then I would go back to the "what else could I do with this time/money?" question.  If the client cares, then whatever you work out with them needs to be the answer.  Be sure to ask them the same time/money question.

One last point.  I don't know what kind of experience your team as with .NET, but you could also look at this as a training exercise.  It sounds like you've got a couple of folks thinking that already.  You have got a working app to benchmark against so you can tell how good of a job you're doing.

Now you're really confused...
Moving to C++ .net can be called "porting"
Moving to C#  must be called "writing a new application"

If you are speaking about an MFC application you must rewrite a large amount of code anyway.
In that case I 'd consider to continue with MFC and to use managed extension for the parts that need the .net framewok
riceman0Author Commented:
Ah, so MFC lives on in .NET?  If we used MFC in .NET, then can we call it a "modernization"?

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

riceman0Author Commented:

"If you are speaking about an MFC application you must rewrite a large amount of code anyway"

I've spent some time with MFC and I'm afraid of this too.  That was the obnoxious thing about MFC, it dictated the whole architecture.  But I'm still hopeful (and I don't know much more than you about their architecture yet) that many of their functions, even classes, won't have to be touched.  They really just want a facelift and a technology update.  Am I hoping against hope?
If you use C++ .net I think you can reuse a number of classes (may be all the classes that have no usere interface).

If you want to give a new look (user interface) to your app you can also consider the "MFC feature pack":

I love MFC, and in my project I often use managed extension to use the facility of the .net world with the "old" MFC architecture
If you truly want a .NET application, I would go C#.  Porting most c++ code (with the exception of UI) to C# is very easy.  It is a bit tedious, but not hard.  The UI is the big problem.  If you really want a .NET app, by which I assume you mean managed code, then you need to rewrite the UI code since MFC does NOT live on in the managed world of WinForms.

As to your pros/cons, your first bullet is not correct.  If you really mean to move to managed C++, the syntax is quite different from unmanaged C++ and C# is actually closer, in my opinion.  Using C++ to write managed code also allows you to make mistakes that don't cuase the program not to work but cause it to work poorly.  This is because your C++ developers will accidentally use unmanaged coding style in places where they should not and the compiler will happily auto-generate marshalling code to make it work and sudden;y your app performs terribly.

If you stay with unmanaged C++ (basically just upgrade to the newer compiler), the port is not bad.  If you followed MFC rules very closely in your original code (it allowed you to be somewhat sloppy, particular with message handlers) you may not have to do much except recompile.

alb66 writes:
>> In that case I 'd consider to continue with MFC and to use managed extension for the parts that need the .net framewok

This is an option, but in that case I'd just keep it all in unmanaged C++ since you don't really gain anything by porting code to do exactly what it did before.  What would the purpose be for doing this?

I'd clarify with your client what they mean when they say they want ".NET technology" and why they think they want it.  For a standalone app that works, there does not seem to be any value in porting.
riceman0Author Commented:
Thanks for the thoughts.  Sounds like we have more options than I thought.

Good to know in particular that it is not a clean port to managed C++.

Sounds like we have more options than I thought.  It sounds like the easiest path is to stay with unmanaged C++?  Are there any disadvantages to this?

The only thing we can discern in the request for proposal as to *why* they want this is "to use Microsoft .net technology to ensure usability on current platforms."  It sounds like they are afraid of obsolesence.

They do NOT specifically ask for improved/updated UI (just a nre function or two), by our read the new forms can look just like the old ones (buttons, text boxes, graphs).
If it is just a matter of obsolescence, and not new UI or managed code that is driving the decision, then just stay with MFC and unmanaged code since it is the easiest thing to do.  Maybe plan ahead for future conversion/porting if significant new features are being planned for your app.  MFC does not appear to be in danger of obsolescence as it is well supported in VS 2008 and in fact just got a set of new features to stay current (see

Planning ahead will gove you time to get your team trained in .NET since there are some interestiing changes in thought process that are required as well as just learning the new languages and framework classes.  Then you will be in a position to do a high quality job on the port.

What will be in danger is being able to find qualified MFC programmers in the future.
AndyAinscowFreelance programmer / ConsultantCommented:
If there are any parts of the app that require high performance then, in my understanding, changing to .net those parts is a bad idea.  .Net allows (according to MS) the coder to write code faster than traditional languages, the code however may run slower even when optimised as much as possible by the coder.
riceman0Author Commented:

drichards: I'm trying to push unmanaged MFC as a viable option, and a couple of my teammates aren't thrilled with that because they feel like that's not modernizing the software.  I make the case (per your point)  that we are making it work with a modern compiler, so they are in better shape from a maintainability standpoint, and it also has the benefit of the least impact on tried-and-true code.  Does that sound like a good argument to you?  Or are they right that you are not really properly "using .NET technology", they read those words as using managed code.

Also, with the unmanaged MFC route, could we use the old UI, the MFC forms (that would be amazing), would they simply port over?  Would they look modern, with the 32-bit style (I could see the client caring about that)?

Andy: good thought; this is analysis software, but not calculation-intensive.  I doubt that performance is a major concern, but we'll keep that in mind.

We are trying to get more info out of the client as to their wishes, maybe even the source code.

BTW, this is a very interesting question.  Please let me know how it turns out in the end.
riceman0Author Commented:
Thanks for the great answers drichards.
riceman0Author Commented:
Oh a follow on as I figure out how to present what I've learned:

Would unmanaged MFC code developed using VS2008  technically be a ".NET application"?  

It's not using any .NET objects, but it's compiled with the same compiler?  Is that accurate?
Managed C++ and C++ are compiled by the same compiler but managed code creates MSIL output and the other produces machine code appropriate for the processor.

It's not the same compiler that compiles C# or VB, which are other, separate compilers.

So no, it would not technically be a .NET app as it does not need .NET framework installed to run (no dependency on CLR).
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.