Need advice in converting in one of the legacy C++ component into C#

Question

Currently, we are working on a C++ legacy code base, which consists of several software components.

One of the components, are written in a way that is extremely difficult to maintain. (For example, memory allocation is done in X place, but memory de-allocation is done in Y place. This make memory management a painful job). Till now, we able to solve (or workaround) all the memory leakage issues.

However, after several rounds of bug fixing, our feeling is that, due to the high maintenance cost of this software component, we are unable to go too far from current milestone.

I know it might be bad to rewrite the source code : http://www.joelonsoftware.com/articles/fog0000000069.html

However, instead of re-factor the current code, we forsee it will be better to re-write from scratch due to

• Till now, no one in the team can fully understand that software component code.
• The legacy software component is a small piece of software. 20k lines, I guess
• Our teams are pretty clear on the requirement and what we are trying to achieve

Hence, we are planning to go for a managed code, at least make memory management a painless job. We plan to choose C#, as

• All our C++ code are compiled using Microsoft VC++
• We are using MFC, in other software components. (in DLL form) Every DLL, do have their very own resource.

I am from C++ and Java background, and know nothing much on C#.

1. How well C# to interface with MFC DLL, with some of the DLL functions will invoke MFC GUI?
2. Anything I need to pay attention on it?
3. Will the interfacing with legacy C++ DLLs be easier, if we are using Managed C++?

Thanks.

Answer 1

How well C# to interface with MFC DLL, with some of the DLL functions will invoke MFC GUI?

Not well at all. You can't P/Invoke to a C++ library -- it works with C exports only. You would need to write a wrapper exposing a C library interface for you to P/Invoke from C#, or you'd need to recompile MFC using C++/CLI. There's little reason to do this though as Winforms is a comparable library to MFC for .NET code.

Anything I need to pay attention on it?

I don't understand that question.

Will the interfacing with legacy C++ DLLs be easier, if we are using Managed C++?

Considering you can't do it using C#, yes. You'd have to recompile those C++ DLLs to have them expose a C interface, or you'd have to recompile them from source using C++/CLI.

---

Note: No matter what you do here, you're still going to have to worry about memory managment and object lifetime of anything going on inside native code. The CLI does not automatically manage native resources for you.

Answer 2

I am in a similar situation and I also did some experiments mixing C++ and C#. The problems in my application however were that:

• the application is not clearly split up in different modules, making it hard to move specific modules from C++ to C#
• the application is quite cpu-intensive and experiments revealed a big overhead in calls from C++ to C# or C# to C++

Additionally, you cannot call C# directly from native/unmanaged C++, which meant that I had to introduce an additional intermediate C++/CLI (or is this called C++.Net?) layer.

Therefore, I chose not to move to C#, but stay with C++.

So, if you want to move from C++ to C#, make sure:

• that you have clearly separated modules
• that the transition (calls) from C++ to C# or vice versa are in a place that is not used that often (so not during cpu-intensive tasks)

Additionally, remember that if you are not the sole developer of the project, that all (or most) of your developers should also learn C#. You don't want to delegate all C# code to your latest junior developer, because if he leaves, you will be (or could be) in trouble.