I have a C++ application. This supports users' C++ plugin DLL's, it will dynamically load these DLL's and then be able to create and use the user's types dynamically. These user types derive from base types and interfaces defined in the main application's core library, so I hold user's objects as pointers to the base class and call the user's virtual functions to make their magic happen.
Now I want to extend the plugin DLL's to allow managed DLL's (I care about C# mostly). I want all of the same magic to happen in C# plugin DLL's.
How can I dynamically load these dll's, some how I think win32's LoadLibrary which I am currently using is going to be happy with a managed DLL. I will not have access to these libraries at compile/link time, they come from the user.
After I get the library loaded, unfortunately I suspect COM in my future as the way to call the derived functions. Possibly I could use the CLI/C++ wrapper I have been reading about but I am very inexperienced here and would appreciate any advice or links to appropriate articles.
Another way of doing this would be creating a C++/CLI project that hosts your C# classes and use it as a bridge in your C++ project.
A few more links to this approach:
Connecting c++ and c# code with a c++/cli bridge
.NET to C++ Bridge
The latest link has simple source code for the bridge
What you'd do is basically start up an instance of the CLR in your process.
Have a look at this article on CLR hosting
Here are some slides that describe my solution.
https://docs.google.com/presentation/pub?id=1YoJRGnveh4By7ym4GL19L7OzYOFORZQB6RgJEPVfFb8&start=false&loop=false&delayms=3000
My solution was to have a win32 plugin dll, loaded through normal means (LoadLibrary) that links to mixed C++/CLI dll, which links to pure managed C# code. I allowed calls to happen both ways using A LOT of boiler plate, and a double c++/cli bridge pattern based off of the link given by Padu. Details were fairly complex, but the job of the end API user is very easy and that was my goal. The managed plugin object writer simply derives from an object, and everything just works.
Essentially I made a pattern that provides "mixed mode pseudo inheritance" Now my c# objects derive from a base class in c++.
Related
This question already has answers here:
Wrapping C++ for use in C#
(3 answers)
Closed 9 years ago.
I have a C++ project which consists of some headers, cpps, some lib files and DLL files.
I want to wrap these files in order to use them on a C# project.
I wanted to make one DLL which will contain the all C++ project and then to wrap it with C# class so I would be able to work with it.
So my questions are (Working with Visual Studio 2010):
How do I make the final DLL file.
a. I know how to link the lib files to the project, but how do i link the DLLs?
b. What do I need to add to my headers in order that the functions declared in them (which are implemented in the lib files) will be imported to the DLL. (What is __declspec)?
After building the final DLL file, how do I create a C# project which use this DLL file?
Thanks in advance
This is called (COM) InterOp. Fortunately one of the major design goals of the original .NET Framework was to facilitate easy interoperability between managed and unmanaged code. Broadly speaking there are three different kinds of interoperability that one may wish to achieve when dealing with managed code.
Making calls into COM components from managed code
Making calls into native DLLs from managed code. This known as platform invocation or colloquially, PInvoke. (This is what you want)
Allowing COM components to call managed code by wrapping the managed code with a runtime callable wrapper (RCW). This can be used as a strategy for the piecemeal replacement of legacy code on a planned basis.
The process by which data is moved from the managed to unmanaged realm is known as marshalling. This is the name by which data and its associated types are serialised across some boundary or other. To support this process there are a collection of classes that exist under the System.Runtime.InterOp namespace.
Broadly speaking the process is essentially as follows:
Determine function names (I use Dependency Walker)
Determine function signatures (Look it up on MSDN if it's a MSFT one)
Determine data types and structures required by code
Write managed code to call into the native code that satisfies the criteria determined above
Test the wrapper code that's after being written to ensure that it produces the expected results (this can often be the most tedious part)
You are looking for C++/CLI. With this hybrid you can write a dll that can contain any amount of normal C++ code and it can contain managed classes that can use .NET types (like System.String) for it's interface and internally handle your normal C++ types. That dll will be usable from C# like any other .NET dll. From the calling programs perspective will look as if you had written it in C#.
Normally answers should contain practical examples, but C++/CLI is a large field to cover, you could write books just describing your scenario. You can find a good tutorial here and a good Overview here.
Attempting to build a C# NPAPI plugin I have found a tutorial which describes that your dll needs to implement a number of methods such as NP_GetEntryPoints , NP_Initialize and NPP_New along with a number of others.
However what I want to understand is if I can simply mirror these method names and construct equivalent datastructures as described in the article (like _NPPluginFuncs) in C# and everything will work?
Could someone please be kind enough to provide some guidance? Is it possible to build a NPAPI plugin in C# and if so what are the basic steps involved?
As stated in the documentation:
A NPAPI browser plugin is, at it’s core, simply a DLL with a few specific entry points
That means you need to export some function from a regular dll, that is done usually in C/C++. Unfortunately it is not possible to expose any entry point from a plain C# dll, but look at this answer, with some effort it appear to be possible to trick some export by some sort of post build tool.
In any case don't expect to pass too much complicated data structures from/to the plugin interfaces, it will be a pain. If you are interested in doing more research the keywork to use is "reverse P/Invoke", in analogy with direct P/Invoke that is calling regular dll from managed world.
The reason a C# dll can't expose directly "entry points" is that entry point are actually just some address inside the dll poiting to some assembly code immediately executable. C# dll are different kind of beast: they are just files containing IL that is compiled "Just In Time" and indeed such compilation is forced AFAIK with some OS tricks. This is the reason reverse P/Invoke is not starightforward at all.
As Georg Fritzsche says in his comment:
NPAPI plugins are basically DLLs with a few required C-exports
and there is no built-in way to export functions (in the C-export sense) from an assembly written in C#.
Some of your options are:
A mixed-mode C++ assembly which can export the functions directly. This could have implications for hosting the CLR in your plugin's host process.
A small native DLL which hosts the exports, then uses COM interop to delegate to a C# assembly containing the plugin functionality. The "official" way to do so-called "reverse p/invoke".
An intriguing project which post-processes your fully-managed assembly, turning static methods marked with a custom attribute into named function exports. (I have no affiliation with this project; I stumbled across it after I got to wondering whether anyone had improved on the COM interop way of doing things.)
In my project I got a device which comes with C++ Sample codes. The codes are ok and the device is working as expected.
But I need it to talk with my C# interface because all other devices are currently using C# interface.
So I am planning to create a DLL Wrapper for the driver. I will create a C++ Library of my own (from source code with proper interface) and Call this C++ Library from C# using DLLImport (just call my interfaces there.).
I am pretty sure it can be done this way, but I have never created a C++ Library and used it from C# yet. So, can anyone refer me to some tutorial that goes with my problem?
I am using C++/C# int VS.NET 2008.
Regards,
Maksud
Have a look at
using a class defined in a c++ dll in c# code
Another useful tool you have at your disposal is C++ CLI.
You can use C++ CLI to create an intermediate library - one that exposes managed classes but runs unmanaged C++ code. You can actually mix managed and unmanaged C++ in the same DLL.
The unmanaged portion can accesses the unmanaged DLLs without having to use the PInvoke functions.
Your C# code can access the managed classes in this intermediate library.
Depending on the DLL and what you need to do you may not need to create a wrapper directly. You might be able to get away with P/Invoke for the functions. You will need to evaluate your specific needs and what is already available in the libraries/code provided.
For anyone who comes to this question and are looking for answers, you may want to try xInterop NGen++ , a C# wrapper generator for native C++ DLL, which has been just released to the public, the tool can generate C# wrapper for native C++ DLL automatically and instantly by using advanced P/Invoke technologies. Check out the current version and a free version will be out soon.
(I am the author of the tool)
Is there a way to create C# objects and call methods from unmanaged C++, but without using COM Iterop? I am looking for something like JNI (but for .Net), where you can manually create the VM, create objects, etc.
If you are using C++/CLI then you can interact directly with both the managed world and unmanaged code, so interop is trivial.
You can also host the CLR yourself, and whilst the hosting API is COM based, you can then create any managed object. The process isn't a difficult as it sounds as a few API calls encapsulate a lot of functionality. There is a lot of info online, for example the MSDN documentation on "Hosting the Common Language Runtime".
There is a somewhat "undocumented" way of exporting C style API from a .NET class / method.
This ultimately leads to a situation where a .NET dll has exported APIs that can be called from C/C++ or anything that can consume .DLLs for that matter.
If you are into "reading" (beh ;) you can get a book called: Inside Microsoft® .NET IL Assembler where you'll find this technique in chapter 15: "Managed Methods as Unmanaged Exports"
There's also a nice example project on code-project you can use as a starting point for 32-bit environments:
http://www.codeproject.com/KB/dotnet/DllExport.aspx
You can decide file-by-file in your C++ project whether or not to use managed C++. Try changing the settings a file in your project so that it compiles as managed. Put the calls there to your C# object.
There's a cost to crossing the C++/C# border, so you should analyse where to do it. Like, you wouldn't want to do it inside a loop.
I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.
The header file used by the C++ dll contains a few user defined type definitions and function declarations.I have browsed many sites and all the posters say that its not possible to import header file into C#.I would like to know if there is any way to import header file into C# code as it is required to declare the functions of the imported dll in the C# application class.
Thanks
This is more or less a duplicate of Importing a C++ dll in C# however that question has some poor "information lite" answers.
Unfortunately there is no short answer to this, however you do have several options.
Wrap your C++ class in a managed C++
class. Then your C# project just
references the managed C++ project,
and everything works.
Like 1, create a managed C++ class,
but create a facade. This a
simplified interface to your class
exposing only the functionality you
need.
The other approach is to use PInvoke
to call the methods on the class.
You'd need to built a C#
representation of the class for the
pinvoke calls. This can be
problematic and involves a lot of
trial and error if you don't know
what you're doing.
All of the above involve learning some technologies that will be new to you (manged C++ or the intracies of PInvoke). Unfortunatly there's no other way.
If you can I'd go with 2.
Have you considered bridging this gap with a C++/CLI project? If you write all your wrapper library and interoperability code in a C++/CLI project you can easily define managed types that expose the defines in C/C++ header files.
When I have submbled upon the same problem - given .h and .lib files intended for C/C++ use, I have written a wrapper for it in C++ with managed extensions. It is really quite simple. Your C++ assembly will play neatly in your Visual Studio solution and you'll be able to single step right from C# into managed C++ into unmanaged C++ and back again light as a breeze! :-)