Link to home
Start Free TrialLog in
Avatar of riceman0
riceman0

asked on

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.
Avatar of alb66
alb66
Flag of Italy image

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
Avatar of riceman0
riceman0

ASKER

Ah, so MFC lives on in .NET?  If we used MFC in .NET, then can we call it a "modernization"?


"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":
http://msdn.microsoft.com/en-us/library/bb982354.aspx

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.
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 http://www.microsoft.com/downloads/details.aspx?FamilyId=D466226B-8DAB-445F-A7B4-448B326C48E7&displaylang=en).

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.
Avatar of AndyAinscow
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.

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.

ASKER CERTIFIED SOLUTION
Avatar of drichards
drichards

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
BTW, this is a very interesting question.  Please let me know how it turns out in the end.
Thanks for the great answers drichards.
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).