C# to C++ port

[Luca]

Hi everyone,

We have a dll component developed in C# and used by the other projects (exe)
written in C#.
This component has been tested and proved to be very robust component and so
we are going to re-use it in another application (very large code base)
which has been already written in unmanaged C++.
What is the best strategy between the following two options:

1. Write a managed C++ wrapper around the C# component and use that wrapper
in our unmanaged C++ project.

2. Port the C# component completely to an unmanaged C++ component and then
use it in our unmanaged C++ project.


The main advantage of option 1 is that it seems much quicker and we can also
benefit from .Net framework library without having to re invent the wheel or
use other 3rd party libraries.

The main advantage of option 2 is that we are not going to get involved in
the potential problems involved in mixing managed and unmanaged codes.

Does anyone have any other ideas (maybe option 3 ...) or see another pros
and cons in going with either option 1 or option 2?

Any help would be appreciated

Luca.

 

[Ignacio Machin \( .NET/ C# MVP \)]

hi,

You are clear of the pro and con of both solutions, it's up to you or your
group to valorate the best way to go depending of your resources, skills and
complexity of both pieces of code

 

[Michael D. Ober]

Given that you have tested and proved robustness of the C# code, I'd write a
wrapper around it. Going with option 2 will involve a lot of testing that
you have already done.

Mike Ober.

 

[Andy]

I agree with Michael. Use the C# dll via interop. Your chances of
hitting errors are much smaller.

 

[Ben Voigt]

Given that you have tested and proved robustness of the C# code, I'd write
a wrapper around it. Going with option 2 will involve a lot of testing
that you have already done.

Additional advantages of making a C++ version are -- no runtime dependency
on .NET Framework, reduced memory footprint, portablity.

Also, if you have a lot of good unit tests for the C# version they will help
a lot with porting.

Even so, unless you are badly constrained for memory or disk space, or need
cross-platform capability, I agree with wrapping the working C# component.

 

[Luca]

If we go with option 2 do you see any issues on performance?
i.e. does the final unmanaged C++ application runs slower if we use wrapper
around C# code compare to when it calls native C++ code?

Also any issue about mixing managed and un managed code (memory management)?

 

[Carl Daniel [VC++ MVP]]

If we go with option 2 do you see any issues on performance?
i.e. does the final unmanaged C++ application runs slower if we use
wrapper around C# code compare to when it calls native C++ code?

I think you meant option 1 - wrap the C# dll in an unmanaged wrapper.

Parts of it will no doubt run slower, other parts may run faster. There's
an unavoidable penalty to pay when the process first loads the CLR and JIT
compiles the classes you're using. Once that's out of the way, you probably
wouldn't see much difference, but that depends a great deal on exactly what
the wrapped code actually does. Using the wrapping technique, the memory
footprint of the resulting app will no doubt be larger - several megabytes
larger. That could lead to performance issues related to paging if the
machine it's running on is highly memory constrained.

In short, the scenarios under which the wrapping solution gives better
performance are few and far between. The scenarios under which is gives
acceptable (if slightly slower) performance are far more numerous.

Also any issue about mixing managed and un managed code (memory
management)?

Sure. Don't try to delete manged memory, and don't leak unmanaged memory.
As long as you keep the two straight, the two systems can coexist
peacefully.

-cd