All versions of Visual Studio of 2015, 2013, 2012, 2010, 2008, 2005 C++ compiler are supported, Visual Studio Express version and Community version are also supported.

If a DLL is compiled and dynamically linked with the run-time library of certain version of Visual Studio C++ compiler, for example, Visual Studio 2015, Visual Studio 2013, Visual Studio 2012, Visual Studio 2010, Visual Studio 2008, Visual Studio 2005, etc, any application using the DLL must be linked to the same version of Visual Studio run-time to use any C++ STL class and C++ functions. All versions of Visual Studio of 2015, 2013, 2012, 2010, 2008, 2005 C++ compiler are supported.

The C++ run-time is automatically detected by xInterop C++ .NET Bridge, and the generated C# .NET assembly will be referencing the corresponding .NET StdLib automatically.

Permalink


What is an instance of native C++ class? It is really just a pointer pointing to the beginning of a memory block of certain size in the native unmanaged world. Okay, that makes sense. If we allocate a memory block of such a size in C# by calling Marshal.AllocHGlobal method and then pass the pointer(IntPtr) to whatever native C++ method in that C++ class, would that work? and How? A block of memory representing a native C++ class instance may not be valid until the block of memory gets initialized by calling the constructor of the native C++ class. Once it gets initialized by the constructor, the native C++ DLL won’t be able to differentiate an instance created from C# or native C++, it is just a block of memory with initialized data with the same constructor method.

Permalink


No, the mangled name is not used in the C# P/Invoke signature declaration. Instead, the ordinal number is used to identify the entry point of a native C++ function in the native C++ DLL. There are a couple of reasons to choose the ordinal number. One is that it is just an integer number, it is short, size of the final .NET assembly is reduced. Two is that the code will look cleaner, not like the mangled name which may be up to hundreds of characters, especially for a function of an instantiated template class. The last is that it is really not a concern to developers since the C# P/Invoke signature shall be generated automatically, it is not meant to be maintained by developers anyway.

The following is an example of declaration of c_str function of the most commonly used native C++ class, std::string.

Permalink


We are assuming you are familiar with calling a C++ native DLL from a native C++ project, which requires you to provide the C++ DLL, the corresponding C++ Lib file and all the header files required to interpret the C++ DLL.

The C# .NET P/Invoke Interop SDK Tool requires the C++ DLL and all the header files without using the lib file which can be generated from the C++ DLL by the SDK tool, which means it will allow you to create C# .NET Wrapper DLL for native C++ DLL if you happen to have no lib file for the native C++ DLL.

Permalink


The SDK Tool comes with a GUI Application called NGenerator, it is a C# .NET Wrapper Generator for C++ DLL. You create a NGenerator project by providing the native DLL and all the header files required to call that DLL from your C++ project, after you build the NGenerator project, it will generate a C# Visual Studio project containing all the required C# files to build the C# wrapper DLL. The native C++ DLL will be embedded inside the C# .NET Wrapper DLL as resource.

Permalink


Yes or No.

If the classes of the C++ DLL has no reference to the classes from boost library, yes it is supported since referencing boost library internally does not make any difference.

If the exported classes does contain reference to the classes from boost library, it is not currently supported, .NET PInvoke Interop SDK might be able to make it work though.

Permalink


Yes. You can.

All C++ standard template library(STL) container classes as I listed below, all of the STL C++ container classes.

are discovered by xInterop C++ .NET Bridge automatically when they are instantiated and used as parameter type or return type and they will be exported automatically in a supplement C++ DLL. If you build your C++ native DLL and use xInterop C++ .NET Bridge to generate C# wrapper classes or libraries, you are not required to export any of the instantiated container classes, no matter how complicated they are, they will be discovered and corresponding C# wrapper class will get generated. You may would want to read the following blog post in details.

Advanced technology to wrap native C++ template class in C# automatically

 

Permalink


No worry, we will export them and then generate C# wrapper classes for them. The only requirement is that the instantiated template class can be exported a C++ DLL.

If you can not even instantiate the template class even from a C++ project, then the chance of exporting the instantiate template class is none. Normally, if you define the template class and the type all in the header files, the chance of exporting the instantiated template class will be higher.

You must make sure you can create that kind of template class in a separate C++ EXE or DLL project if you are concerned about the possibility of creating wrapper class for any instantiated template classes which are not exported.

Permalink


Yes. It does support creating C# wrapper classes for the instantiated C++ template classes.

For example, if you have an instantiated template class, such as std::vector<int>, the wrapper generator will generate StdIntVector for it, any type of std::vector<int>*, std::vector<int>&, return type of std::vector<int> (object, pointer or reference) can then be marshaled to StdIntVector automatically by the C# wrapper code generator.

There is limited support if class object is passed by value to any method of a class. Since the SDK Tool only builds fully managed .NET wrapper library, it does not use unsafe keyword, any class object passed by value can not be passed by using the native pointer of the C++ class object. So far, we have only tried passing a std::string by value. So the support of passing class object by value is limited.

Permalink


Not really, Itanium is not supported. Since the support of Itanium will be dropped eventually, there is no need to support Itanium.

AnyCPU architecture is supported if both of the corresponding native C++ DLLs are available. If only one of the native C++ DLLs is available, then only the C# wrapper DLL targeting that native C++ DLL will be generated, x86 or x64, but not AnyCPU.

Permalink


Yes. A C# enum type will be generated for any type of C++ enum used either in any of the interface of C++ classes or the structs used by any of the interface of C++ classes.

Permalink


Yes. A C# struct will be generated for each C++ struct which is part of any interface of any C++ class, any struct within a struct will be generated as well.

Permalink


Sure, if that is what you really what. We would like to make it very flexible for you, the decision is yours. Since they are private fields which are not supposed to be accessed from outside of the class, you have been warned.

The .NET PInvoke Interop SDK can let you choose to implement private fields as private, protected or public properties in C#, but once again, you are breaking the contract of the C++ class by letting the private fields to be accessed from outside of the C++ class.

There is one thing to keep in mind, since private fields are designed to be accessed only from inside of the class, not all of the types of the fields are known to C# wrapper class through the C++ DLL interface, some of the field types may be internal to the C++ DLL hence there may be no way to create or manipulate them from C# no matter what.

Permalink


Sure, if that is what you really what. We would like to make it very flexible for you, the decision is yours. Since they are private members which are not supposed to be called from outside of the class, you have been warned.

When you export a C++ class, the private functions of that class are exported as well. You can disable it by exporting the functions individually though. The .NET PInvoke Interop SDK can let you choose to implement private methods as private, protected or public methods in C#, but once again, you are breaking the contract of the C++ class by implementing with different kinds of C# access privilege.

There is one thing to keep in mind, since private functions are designed to be called only from inside of the class, not all of the parameter types can be created from C# through the C++ DLL interface, some of the parameter types may be internal to the C++ DLL hence there may be no way to create them from C# no matter what.

Permalink


It has to be C# because a C++ object instantiated from C# lives inside of a managed C# object, it eventually will be garbage collected by the .NET framework and the memory of the native C++ object will then be released, any native memory or resource allocated by the native C++ object will be released as well. If you want to stop the C++ object from being garbage collected during the time when the C++ DLL still tries to access it, you will need to put a lock on the C# object to prevent it from being garbage collected, and then remember to unlock it when you are sure the native C++ DLL no longer needs to access it. There are surely ways we can implement to let the C# .NET object to dispose itself automatically when the the C++ object gets deleted from the C++ DLL, but it will certainly slow down the P/Invoke procedure and affect the performance of P/Invoke, so we decided we currently do not implement it.

Permalink


Yes. You surely can, otherwise you won’t be able sub-class the original C++ class at all. The virtual methods of the C++ class are implemented as C# virtual methods, you can override them from your deriving C# class. Due to the limitation of C# language itself, multiple inheritance is not supported.

Overriding virtual methods from C# does have cost, the C# wrapper class of the original C++ class will have to set up the native virtual function table and all the C# virtual methods to make it work. So overriding virtual method is not enabled by default, but it can be enabled programmatically from your code of the deriving C# class of the C# wrapper class.

Permalink


Yes. It does support sub-classing C++ classes or inheriting from C++ classes. You can define your C# classes inheriting from the C# wrapper class, logically, the deriving C# class will become a subclass of the original C++ class. Marshaling the deriving C# class to the original C++ class will be just like passing a native object of the C++ subclass. From C# code, you can access an instance of the deriving class just like accessing a C++ subclass of the original C++ class, or just the original C++ class, It will be treated as a C# wrapper class of a C++ subclass of the original C++ class. The C++ DLL does not see a difference of the C# deriving class and the original C++ class.

Permalink


Yes or No. It does not support wrapping C style DLL directly.

We would want to focus on only C++ DLL for now because there are already such tools like PInvoke Interop Assistant can be used to generate .NET wrappers of function P/Invoke for C style DLL exporting functions only. And there are no other tools which can generate .NET C# Wrapper for C++ DLL automatically without developers’ manual involvement, such as writing extra C# code or script code, so working with C++ DLL is our highest priority.

If you really want to create C# wrapper for C style DLL using xInterop NGen, a simple work-around for you is to create a simple C++ wrapper class to call all the C style methods. This is actually very simple, your probably can wrap up dozens of methods in half an hour.

Permalink


Yes. Both of C++ string (std::string) and C++ wide character string (std::wstring) are supported. The .NET PInvoke Interop SDK marshals a C++ string to StdString, a C# wrapper class for standard C++ string class(std::string) and mashals a C++ wstring to StdWString, a C# wrapper class for standard C++ wstring class(std::wstring). C++ string will be marshaled to ANSI encoding, C++ wstring will be marshaled to Unicode encoding.

Permalink


Yes. All the public non-static field members are accessible and all the non-static protected field members are accessible via inheritance.

Permalink


Yes. All the public static field members are accessible and all the protected field members are accessible via inheritance.

Permalink


Yes. All the public and protected static function members are accessible directly or via inheritance. The public static function member is implemented as public static method in C# wrapper class, the protected static function member is implemented as protected static method in C# wrapper class. The underlying method of pinvoke C++ class method is hidden from developers.

Permalink


Yes. All the public and protected non-static function members are accessible directly or via inheritance. The public function member is implemented as public method in C# wrapper class, the protected function member is implemented as protected method in C# wrapper class.

Permalink


Yes. It supports P/Invoke native C++ class. For every exported class in the C++ DLL, the C# Wrapper Generator for C++ DLL will generate a corresponding .NET C# wrapper class in the C# wrapper library. The C# wrapper class implements exactly the same interface of the original C++ class, which makes developers feel like calling (P/Invoke) C++ class method with the convenience of using it from C# language. The C# wrapper class can be created in C# hence the C++ class can be instantiated from C#, the C++ DLL will see no difference between the object of C++ class created from C# and the object created from C++ DLL.

Permalink


No, it is not supported yet. We do have plan to make it work against mono, but our highest priority is to make .NET PInvoke Interop SDK to work as smoothly as possible on the Windows Platforms including Windows Embedded Compact. We do understand there is no C++/CLI on mono platform and PInvoke C++ class method is very challenging using mono.

Permalink


No, it is currently not supported, but we are busy working on it.

Microsoft will be releasing Windows Embedded Compact 2013, Windows Compact Framework 3.9 will be released at the same time. PInvoke C++ class method in Windows Compact Framework is currently impossible. Wrapping C++ classes in a shared library in C Style methods in another DLL is currently the only way that developers can access the functions of those C+ classes in a C++ DLL, but it is really time-consuming if you look at the picture of wrapping them in C style method. We are currently working on a prototype of enabling our C# Wrapper Generator to output C# code which are compatible with Windows .NET Compact Framework, there are differences between desktop version of the .NET Framework and the compact version, we are looking into the details. Please stay tuned if you are Windows CE developers. We will try to make pinvoke C++ class method as easy as you write code using C#.

Permalink


Yes. Visual C++ Compilers including Visual C++ 2015, Visual C++ 2013, Visual C++ 2012, Visual C++ 2010, Visual C++ 2008 are currently the compilers supported on Windows platform.

Permalink


If you have the following c++ method, how can you create a C++ std::vector<std::string> object and pass it to C++ native DLL using the C# wrapper library for C++ run-time?

To call the native method, let’s define the P/Invoke signature first.

And then, you can instantiate an object of StdStringVector, populate the content and pass the object to the native method. You have successfully passed a std::vector<std::string> object from C# to native C++ DLL.

Permalink


If you have the following c++ method, how can you be able to call the method using the C# wrapper library for C++ run-time?

Here is the P/Invoke you need to define in C#.

Now, you can call the method from C# and access the content of the string vector.

 

Permalink


Translate »