Is there a way for a Shared Object file written in C and built on Unix to be called from C# P/Invoke?
Or do I need to use Java or something like that?
Mono has the ability to integrate with native libraries from within C# built on top of dlopen(3). You just have to use the DllImport statement with the name of the library (i.e. 'libform.so.5'), then wrap the native code and data types with a friendly C# class that takes care of all the low-level stuff. This page has a good overview with lots of information on how to deal with marshaling pointers and other unsafe types.
Once you've got your wrapper class written, you can just use that without worrying about the fact that it's using a native shared library underneath.
I would say at the least there's likely to be no easy way, especially if you mean C# on Windows. In that case you would need something that would be able to decode the shared object and get to the code in it, sort of a re-implementation of the ABI for GNU/linux. Also, any other libraries would have to be present and usable as well, such as the C runtime library and the like. This would likely be a very significant effort.
As for doing it directly under linux/Mono, see this answer: Calling UNIX and Linux shared object file .so from c# .
You could also try to see if what open office does, http://packages.debian.org/lenny/cli-uno-bridge could be helpful; but this is more of an interface rather than directly linking the two together.
Related
After days of experimenting that only led to partial success, I'd like to ask whether I have any chance or I'll invariably end up in a dead end. I have an UWP C# App, the usual framework, planned to be distributed in the Windows Store. And I also have a data package written in C++ (mostly C) that I used earlier. The old, non-managed code doesn't call any Windows API at all, it's just a data format package. But I need to access it directly from the C# side, and its most important type is authored as a value struct, with many overloaded operators (and this is good so, that approach is just perfect for the application domain).
From a WPF application, I wouldn't have any problem at all, a C++/CLI wrapper of a value struct, exposing everything. But the UWP app doesn't want to do the same. If I use the same C++/CLI wrapper, although I can get it to compile by itself, the UWP project will flat out refuse to reference the C++/CLI project.
I also tried the newer C++/CX flavor but that comes with many limitations, no specialized constructors, no overloading. It seems to be sandboxed much more than I'd need.
Is there any solution I missed? Maybe still using the C++/CLI (which has the benefit of being already written :-) ) somehow from under an UWP application?
Starting with version 1803 you should have access to a complete C++ implementation
C++/WinRT is an entirely standard modern C++17 language projection
for Windows Runtime
If you want to consume C++ code from C#, then you probably want to compile it as a Windows Runtime Component, as those can be consumed in any other UWP-supported language.
I think this is demonstrated in this documentation, even through the app consuming it seems to be in C++
In the end, I succeeded. There is an intermediate helper class (not a struct because of the inherent limitations) written in C++/CX, and the actual struct I use is defined in C#, using this intermediate.
The error messages in the process were mostly related to the underlying code being very old, C, not even C++, with all the linking and externing stuff involved. But no matter how old it is, it still works...
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.)
I am developing a complex library in C++ and i plan on having a C interface so others can load up the DLL and easily access the lib. I haven't tried writing code in C# that access C code. I did a quick google and found code that uses a lot of attributes.
What can I do to keep my interface simple enough to not cause a headache trying to keep .NET in sync with it? Is there some kind of header generation tool i may use? Do i only use simple POD structs? I'm unsure how i should handle types as they are passed around as pointers. I am also thinking maybe i should avoid using anything that is a not an int/string or array.
I am developing it using MSVC but mostly using it with GCC. I know i should use the calling convention __stdcall. Beyond what i said i am totally clueless. I actually dont know how to load the DLL into .NET.
What can i do to ensure everything works correctly when writing my C lib and getting it to run with .NET?
Consider putting together a COM interface. Consuming COM from .NET is marginally easier than P/Invoke; at least you won't have to spell out prototypes for all functions in C#, the COM typelib importer will do that for you.
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++.
Like a lot of places my workplace has legacy code floating around along with more modern applications. For example we have a server application that still uses the Microsoft Fortran77 compiler. The less old parts of the application are written for the Visual Studio 6 C compiler and lately there have been runours of writing some new libraries with VS .Net 2008 C++. The programs/libraries have a number of different mechanisms to consume/communicate each other including static linking, shared memory (Windows memory mapped files), name pipes and TCP sockets.
What's to stop a C# application from being able to use any old library such as one of the Fortran77 ones written in a procedural langauge?
If my C# application understood the file format of a Fortan77 or C library and was able to locate the procedure call it wanted could it marshal the managed objects across, call the procedure and unmarshal the result?
If I copied a .so library file from Linux to Windows and my C# application understood the file format could it call functions from that library?
I think the answers are to do with the various Fortran, C etc. runtimes that are needed to initialise each library/program. If that's so then at a fundamental level are those runtimes the broadly similar to the CLR (realising they have different features such as memory management etc. etc. in the CLR's case)?
Edit:
To put my question another way. If an alien dropped in and gave me a binary library file and a file format specification could I use it from C#?
If the DLLs are valid DLLs and the functions exported use well-known calling conventions, then there should be no problem as long as you get the method signature in .NET right i.e: correct argument types and return type. CLR doesn't (and can't) care what language was the library written in.
As for the Linux shared libraries, if you have the sources of the libraries, it should be possible to compile them for windows using either Cygwin or MiniGW.
I don't know about Fortan77 or .so library from Linux, but I do know that you can use PInvoike with C libraries for method calls. Also you may want to look at the unsafe keyword in C# for the shared memory applications. It allows you to drop out of memory management, which may be what you need. Named Pipes and TCP sockets can be done from the System.Net namespace.
Basically everything you have said can be done. I don't know how hard or easy it will be to accomplish, but you should be able to access all these native apps from your C# application.
You can also create a C++/CLI DLL (/CLR option when compiling) which will allow you to write both in managed and unmanaged code. This allows you to do just about anything you could do in native C++, and also interact with .NET components. I am doing something like this to bridge an old C application with a C# DLL by having the C++/CLI dll essentially sitting between them.