Solved

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

Posted on 2008-11-03
14
828 Views
Last Modified: 2013-11-20
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.
0
Comment
Question by:riceman0
  • 6
  • 5
  • 2
  • +1
14 Comments
 
LVL 19

Expert Comment

by:alb66
ID: 22868389
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
0
 

Author Comment

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

0
 

Author Comment

by:riceman0
ID: 22868495

"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?
0
 
LVL 19

Expert Comment

by:alb66
ID: 22868665
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
0
 
LVL 19

Expert Comment

by:drichards
ID: 22868718
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.
0
 

Author Comment

by:riceman0
ID: 22868857
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).
0
 
LVL 19

Expert Comment

by:drichards
ID: 22873220
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.
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 44

Expert Comment

by:AndyAinscow
ID: 22874206
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.
0
 

Author Comment

by:riceman0
ID: 22906194

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.

0
 
LVL 19

Accepted Solution

by:
drichards earned 500 total points
ID: 22906664
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...
0
 
LVL 19

Expert Comment

by:drichards
ID: 22906674
BTW, this is a very interesting question.  Please let me know how it turns out in the end.
0
 

Author Comment

by:riceman0
ID: 22906694
Thanks for the great answers drichards.
0
 

Author Comment

by:riceman0
ID: 22906811
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?
0
 
LVL 19

Expert Comment

by:drichards
ID: 22906942
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).
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

This article shows you how to optimize memory allocations in C++ using placement new. Applicable especially to usecases dealing with creation of large number of objects. A brief on problem: Lets take example problem for simplicity: - I have a G…
Go is an acronym of golang, is a programming language developed Google in 2007. Go is a new language that is mostly in the C family, with significant input from Pascal/Modula/Oberon family. Hence Go arisen as low-level language with fast compilation…
The viewer will learn how to user default arguments when defining functions. This method of defining functions will be contrasted with the non-default-argument of defining functions.
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.

706 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now