I have a C++/CLI wrapper for a C++ class which I create several instances of in a C# application, and this works fine, except for the functions in the C++ code which take a buffer from the calling function and fill it with whatever is received a call to recv, similarly some functions take a packet to be sent as a parameter.
In the C++ code there are several structs that define all the packet structures, pointers to which are taken as parameters, and I have equivalent C# structs which are packed in the same way so that they appear exactly the same in memory, what I don't know is what C++/CLI type I can use as parameters for functions that take pointers to C# structs, and can be passed to the C++ code.
Thanks.
You don't need any special “C++/CLI type”, you need just the C++ type. If it is a simple C-like struct (no virtual method tables or anything like that), then you could try using Marshal::StructureToPtr(). If it's not that simple, you probably need to copy it from the C# object field by field.
Related
I currently have a large C++ library that I need to incorporate into a C# project. I was successful in using DllImport to get access to some functions from my library, like this:
[DllImport("MyLib.dll")]
public static extern int SampleFunction(string param);
However, I can't seem to figure out how to make it work for functions that either have a parameter or return type that is not defined within the dll itself (i.e., the code in the dll imports it from another file), such as this example function that takes in a list:
[DllImport("MyLib.dll")]
public static extern std::vector<MyClass> MyFunction(string param);
For std library functions, I know I can get the dll and import that in, but what about other classes like MyClass in the above example? Do I need to create a managed wrapper class in C++ for each of these classes, or is there another way to do this?
std::vector<MyClass>, or indeed any unmanaged C++ class, cannot be used for interop to C#. Indeed, even if you wished to consume this function from another unmanaged C++ module you'd have to make sure that you were using the same compiler and dynamic runtime as the DLL which exported the function.
You'll need to find some other way to implement this functionality. There are lots of different ways to do that.
You could expose a p/invoke interface to the functionality. That would likely involve declaring a struct to represent the data of your class, and serializing to and from that struct.
You might consider a COM interface but it won't offer great advantages over p/invoke. You'd still need to serialize your class.
A C++/CLI wrapper would be yet another option. You'd wrap the unmanaged class with a managed C++/CLI class, and then consume that from the C#.
If you need a custom class from a native lib, you'll probably need to export a type library or use managed C++ to write a wrapper. What you're effectively trying to do is marshal a piece of memory from native to managed and now have to deal with how the data type is marshaled.
If at all possible, I would actually recommend trying to do away with the marshaling as when it works it's fine, but when it breaks, it can be rage inducing to debug.
Regardless, I'm actually not sure if anything in the STL can be marshaled. At the very least, I have never seen it done. More times, I've had to do a conversion like so: How can I marshall a vector<int> from a C++ dll to a C# application?
If you want to marshal an actual class, the standard way I've done it up until now is through a type library: Import TLB into C#
Or by linking a native lib into a managed C++ class and then referencing the managed C++ dll into the C# project as a shim.
Beyond that, if you can convert the class to strict C-style functions and pass a struct around, that could allow you to just use pinvoke, this is no different from simply exporting a bunch of helper functions except you can marshal a struct representation back and forth: Marshal C++ struct array into C#
I want to declare a COM Interface in MIDL that allows for returning a pointer (like in the ID3D11Blob). I understand that pointers are a special thing in COM because of the stubs generated for RPC calls. I do not need RPC, but only want to access the COM server from C#. The question is: can I declare the interface in such a way that the C# stub returns an IntPtr? I have tried to add [local] to enable void pointers, but that does not suffice.
The interface should look in MIDL like
[local] void *PeekData(void)
and in C# like
IntPtr PeekData()
Is this possible? If so, how?
Thanks in advance,
Christoph
Edit: To rephrase the question: Why is
HRESULT GetData([in, out, size_is(*size)] BYTE data[], [in, out] ULONG *size);
becoming
void GetData(ref byte, ref uint)
and how can I avoid the first parameter becoming a single byte in C#?
This goes wrong because you imported the COM server declarations from a type library. Type libraries were originally designed to support a sub-set of COM originally called "OLE Automation". Which restricts the kind of types you can use for method arguments. In particular, raw pointers are not permitted. An array must be declared as a SAFEARRAY. Which ensures that the caller can always index an array safely, safe arrays have extra metadata that describes the rank and the lower/upper bounds of the array.
The [size_is] attribute is only understood by MIDL, it is used to create the proxy and the stub for the interface. Knowing how many elements the array contains is also important when it needs to be copied into an interop packet that's sent on the wire to the stub.
Since type libraries don't support a declaration like this, the [size_is] attribute is stripped and the type library importer only sees BYTE*. Which is ambiguous, that can be a byte passed by reference or it can be a pointer to an array of bytes. The importer chooses the former since it has no hope of making an array work, it doesn't know the size of the array. So you get ref byte.
To fix this issue, you have to alter the import library so you can provide the proper declaration of the method. Which requires the [MarshalAs] attribute to declare the byte[] argument an LPArray with the SizeParamIndex property set so you can tell the CLR that the array size is determined by the size argument. There are two basic ways to go about it:
Decompile the interop library with ildasm.exe, modify the .il file and put it back together with ilasm.exe. You'd use a sample C# declaration that you look at with ildasm.exe to know how to edit the IL. This is the approach that Microsoft recommends.
Use a good decompiler that can decompile IL back to C#. Reflector and ILSpy are popular. Copy/paste the generated code into a source file of your project and edit the method, applying the [MarshalAs] attribute. Advantage is that editing is easier and you no longer have a dependency on the interop library anymore.
In either case, you want to make sure that the COM server is stable so you don't have to do this very often. If it is not then modifying the server itself is highly recommended, use a safe array.
I think I found the solution on http://msdn.microsoft.com/en-gb/library/z6cfh6e6(v=vs.110).aspx#cpcondefaultmarshalingforarraysanchor2: This is the default behaviour for C-style arrays. One can avoid that by using SAFEARRAYs.
I have to send a list from C# to C++.The C# list is List<string>MyList and the C++ code accepts it as list<wstring>cppList.How to use marshalas for this.
Thanks
It is always wiser not to use complex type marshaling between native code and managed code.
In case of List, these type totally differ from each other as they have different memory layout for each item.
So the best way is to write a utility function in a native dll that accepts array of string(char*) and manually build your native List and ultimately call the desired method. It is easy for your to create wrapper of that utility function.
C# cannot P/Invoke complex C++ types. You will have to use C++/CLI, they might have a method for marshalling it across. Else, you will have to marshal each string across individually.
strings in C# are wstrings (2 byte unicode strings), so if what you say is true, then no special conversions are necessary.
I'm after help on how to use complex objects either as return values or passed as parameters to C# class methods exposed to unmanaged C++ as COM components
Here's why:
I'm working on a project where we have half a dozen unmanaged C++ applications that each directly access the same Microsoft SQL Server database. We want to be able to use MS-Sql/Oracle/MySql with minimum changes and we've decided to implement a business logic plus data layer exposed via WCF services to get the required flexibility.
This strategy hinges on being able to get the unmanaged C++ to interop with the WCF service. There are a number of ways to do this, but the strategy I want to follow is to create a C# assembly exposed as a COM component which will act as a bridge between C++ and the WCF layer. This C# assembly will be loaded into unmanaged C++ process as COM component.
The C# bridge assembly will contain a helper class which has a number of methods that describe the operations that were formerly expressed as direct sql or stored proc calls in the C++ code.
I have two problems to solve
1) For an INSERT, I need to pass an object representing the entity to be inserted. On the unmanaged C++ side, the I already know that one of the entities has about 40 properties which have to make it into SQL - I don't want a C# method with 40 parameters, I want to pass an object; I don't know how to marshal a C++ object via COM into C#, so I thought about defining a Stuct on the C# side and then make the Struct COM visible.
2) How to return the result of a "SELECT this, that, other, ... ". I've seen two examples. One returns a struct[] and another returns a single struct containing a string[] for each column field and an int count member describing the length of the other member arrays.
On the C# side, I think it will be a case of defining and exposing a number of request/response structs which will be used to pass data in/out. These structs will need to be decorated with attributes that cause their members not to "change position" as a result of optimization. And the struct members may need to be decorated with the attribute that hints to the marshaller how the member should be exposed in COM.
Then of course I'll have to work out how to instantiate and populate these structs as seen as COM objects from the unmanaged C++, then I'll have to pass them in method calls and process them as return values.
This is the most difficult part for me; I grok C++ and some MFC/ATL but COM under C++ is a whole extra level of complexity. Any recommended books, blogs, tutorials on the subject of parameter passing and return value processing as I've described would be very helpful indeed.
If possible, I'd avoing bringing COM into the picture. If you control the C++ code (it sounds like you do), it should be easier to add a single C++/CLI cpp file that calls into your C# code. C++/CLI can directly access and create managed and unmanaged types and copy between them.
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#.
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.
What you want to do is not easy at all. If you really wanted to do it, your best bet is to create some clean, C interfaces that wrap all of the C++ and STL stuff and pass around structures that can pass from .net to C nicely. Depending on how big of a codebase you have, it can be a very difficult task.
Sorry.
maybe you should write a com wrapper and then use .net tool that will automatically create c# assembly for you?
doesnt SWIG create a C-style wrapper for C++ for you? Like handing all the non-basics of complex c++ ? Correct me if i'm wrong because I'm in a similar situation, I want to wrap a very large and complex C++ api exposed in a dll..i need to avoid mangling and the non basic data types by writing a C-style wrapper to expose all the stuff before Pinvoking that and it is infeasible without automated tools given the size of the api and the complexity of the types and prototypes.