views:

92

answers:

2

Hi,

I currently have a huge project that I've recently converted from VC6 to 2005. Now I'd really like to create a new frontend for some of the functionality, However the main logic of the program is based in c++. Also the code base revolves around it's own metatypes and bespoke classes.

The best solution I can come up with is to call functions from the C++ project dlls. However this leads to a huge data marshalling investment where data crosses boundaries between c++ and c#. I was wondering if there are any other alternatives (a complete re-write is not an option).

Thanks Rich

+1  A: 

If you want to create a managed front end for a native DLL, you will have to Marshal data back and forth. There is really no way to avoid this problem.

We're currently facing a similar issue in one of our current projects. The approach we've taken is to use PInvoke to talk Managed -> Native. With a few exceptions, we only PInvoke blittable types which helps reduce the cost of marshaling because the CLR can just implement it as a memory copy.

When communicating native -> managed, we use COM objects. We try to apply the same rules with regards to blittable, but we've found that you often have to include many COM objects in this scenario which prevents blittable-ness.

Taking this approach worked quite well from us. We spent a bit of time up front getting the primitives defined for the data marshalling. But after that, marshalling became ... routine for lack of a better word. It's an overhead but it's a lot cheaper than a full rewrite.

JaredPar
A: 

I've used C++/CLI (which used to be called Managed C++) to handle interop before - it can be a better option than P/Invoke if you're already using C++. A lot of the interop "just works", and you'll get compile-time safety instead of hairy runtime binding, which you may or may not care about.

Jim Arnold