VC++ to C# migration guidelines/approaches/Issues

We are planning to move few of our VC++ Legacy products to C# with .NET platform.. I am in the process of collecting the relavent information before making the proposal to give optimistic and effective approach to clients. Am looking for the following details.

1. Any general guidelines in migration of VC++ to C#.NET
2. What are the issues that a team can face when we take up this activity
3. Are there any existing approaches available ? I believe many might have tried but may not have detailed information, but consolidating this under this 开发者_如何学编程would help not only me but anyone who look for these information.
4. Any good / valid resources available on internet?
5. Any suggestions from Microsoft team if any Microsoft people in this group?
6. Architecture, components design approaches, etc.

Please help me in getting these information, each penny would help me to gain good understanding..

Thanks in advance to those who will share their wisdom thorough this query.

Often, my best advice is: Don't do it.

If you have functioning, clean C++ code, there is no reason to rewrite it. It is very easy to use C++/CLI to build wrappers around the legacy code to make it usable from C#/.NET.

This is often a better, quicker, and safer approach. You can then do your new development in .NET, and slowly migrate any existing code required if there is a real need to do so.

That being said, migrating code from C++ to C# is typically very much a complete, from scratch rewrite (unless you wrap as mentioned above). This is primarily because of the huge difference in libraries, not the difference in languages.

The .NET Framework provides a huge library of tools that can, and should, change the architecture of your code when written. If you just directly port the C++ to C#, you'll find that you'll be doing a lot of things in non-standard ways, and you'll end up with very difficult-to-maintain C# code.

My suggestion, based on my experience, is to wrap your code first. Then, if you decide you need to extend certain functionality, and it's unweildy because of the wrappers, you can rewrite that one specific portion of your code in C# using completely new techniques and libraries - and replace the C++ piece by piece.

One gotcha, if you have a complicated class hierarchy, note that C# doesn't support multiple inheritance, so you may have to rethink the structure of your program.

Edit: Another thing to keep in mind is that the .net framework is very, very big. You may find utility classes in your c++ code that can be completely replaced by standard library classes in c#.

I've had extensive experience in the past of migrating a big application from C++ (MFC) to C# (WinForms).

Some key factors can affect your strategy:

1. First of all, why do you have to migrate? Know your goals to choose a proper strategy. In most cases, you should not migrate "just" so that you are using a cool new technology.

2. How big is the existing code base? If it's a very small code base which is only a matter of, say, weeks to rewrite, don't bother with over-analyzing and just do it...

3. Do you have to convert all the existing functionality to C#? Or can you live with keeping the C++ and only adding new features in C#? Depending on how your existing C++ code is componentalized, you may be able to use technologies such as COM Interop to continue reusing it while developing in C#.

4. Can you afford to delay the release of any new version until you rewrite everything? Usually the answer would be no. (Netscape kind of comes to mind - you may want to read this...) You may want to come up with a strategy where you can gradually replace components and frameworks in your application, in a way that leaves you free to release version upgrades, so that each version has a little more C# and a little less C++ in it.

5. Basically, an approach that worked for me was to rewrite my application's basic frameworks in C#, and consume those frameworks from my C++ application, using COM Interop. Each release had some more frameworks and controls in C#. Once we converted a critical mass of the code, as well as all the controls of our main window, we changed the application's entry-point to be .NET instead of C++.

6. As for resources, for me, the book ".NET and COM: The complete interoperability guide" was a treasure.

That's the main things I can think of right now. I may be able to answer lots of more specific questions you may have.

Some things that come up instantly:

• Make sure you don't confuse the C++ "char" and the C# "char". You probably know that a "char" in C# is not really one-byte primitive. So, in the process of porting you might get confused, pay attention that in C# you port the C++ "char" to "byte".

• As Brennan Vincent said, C++ supports multi-inheritance while C# doesn't. You'll probably have to re-think the hierarchy, if your classes are "complex".

• Pointers are NOT native in C# as in C++. Again, it depends how you wrote your C++ app but I can bet you're using pointers there, so make sure the usafe corresponds with C#'s because it handles them differently, transparently from the programmer (in most cases).

I might add a few more later, nice question!

First, don't take your working native C++ code and compile it as C++/CLI. You will get horrible results. Second, don't take your working native C++ code and try to translate it into C#, while simultaneously noticing places to use the Base Class Libraries, changing your data access technique, and adjusting your UI paradigm from MFC to WPF. You will spend a LOT of energy to produce, at best, what you had before.

Instead, take your working native C++ code and refactor it so that you have one or more "business logic" libraries. If these already exist then they might have COM interfaces, they might expose some "extern C" type functions, or they might expose some C++ instance methods. No worries. If they don't already exist, you have two choices. If there are just a handful of methods needed by the presentation layer, and they take simple things like strings, put some "extern C" functions in the place as gateways to the business logic. Now you can call those from the managed UI (VB or C#, Windows Forms or WPF, whatever) using P/Invoke. If there are a lot and you want to organize them, or if they need to take complex structs or objects then write a C++/CLI class or classes that can talk to the native C++ classes as-is while exposing "public ref class" classes to the managed UI. The C++/CLI will make the marshaling and lifetime issues simpler.

For your new UI, write it from scratch, calling into the business logic where needed. Use the old UI only as a guide to the capabilities you need and to validations. Use the "look and feel" of your new UI technology (WPF or whatever) to build the UI itself and don't try a mechanical conversion. You'll just end up chasing pixels and working harder than you need to if you stick too closely to the old ui. Old app had 3 buttons and a checkbox? Great, 3 WPF-looking buttons and a WPF-looking checkbox coming up. Rather switch to a ribbon while you're making the change? Fine. It's ok to look different when you're done.

Then you deploy your native business logic libraries, still compiled as native code, your C++/CLI wrapper if you have one, and your managed UI. This will work for anything except the phone.

I just need to say again please DON'T port your working native C++ business logic into C# as part of the initial phase of the project. When it's done and working, if you have a good business reason (like we don't want to spend money on C++ devs any more) then you can consider it. But first get it working using interop. This has the advantage that if your translation messes up delicate business logic written by people who are no longer with you, relying on C++ subtleties your current team doesn't know, you can fall back on the wrapped libraries for the rest of your days.