C#/C++ pInvoke tips

Whats the best way to go about modifying a C++ program to be used with pInvoke from C#.NET CF?

I have a large C++ codebase which makes extensive use of STL. Namely iterators, container classes, and standard strings.

On top of this many lightweight classes are passed around by value.

I want to build a C# gui ontop of this codebase for windows mobile touch devices.

Is it worth it?

I have managed to get some examples working using pInvoke to call C++ code from C#.NET, but writing wrappers for every access point and for all the STL return types seems very daunting and ugly. Is there another way or am I somewhat stuffed?

BTW. Managed C++ is not an option becuase its not supported in any form by .NET CF.

--edit: I have one specific question in regards to pinvoke.

Suppose you had a function returning a C++ string by value

std::string foo () {
   return std::string ("Hi");
}

I understand that its not possible to call this function from C# using pinvoke because there is no way to marshall the STL string, but my problem is that I cannot even write a wrapper without allocating a new array becuase the std::string returned is not on the heap.

char* foo2 () {
   return foo().c_str(); //Very bad
   //the returned pointer is released when the std::string falls out of scope.
   //and will be invalid before the caller is able to do anything with it.
}

So my problem is, how to wrap foo into a pInvoke suitable format without needing to re-allocate the whole string.

char* foo2 () {
   std::string f = foo();
   char* waste = new char[f.length()+1];
   strcpy (waste, f.c_str());
   return f;
}

The thought of doing the above for every point at which I need to return a std::string is enough to make me give up trying to use C#.

Solution

I would personally say it's worth it, but I agree with the other post that it's not easy.

Possible approaches may be:

C interface around the C++ and exposed as a DLL.
COM objects (altho WM does not support COM servers so you are forced to use in-proc servers, basically a DLL COM implementation). This would give you a more OO interface.
Background process exposing some sort of API. You could go down the "CE Services" modal or come up with your own API.

All are possible and have there pros and cons. Whatever you do, you can't use STL types in the interface. You have reduced to simple basic types that are easy to marshal between the processes. Since your talking about C#, then COM may be go as you can expose OO interface.

I would recommend trying to keep the interface between the two as simple as possible.