views:

51

answers:

2

Here's the setup:

I've got a shared library (c++ with extern "C" methods) I've compiled in linux and created a library.so file.

I've used Mono Develop on the same box (Ubuntu) and was able to DLLImport("library.so") and access my extern functions no problem.

The problem comes in when I copied that .so file to a windows machine (Win7) and I try to do the same thing, but this time running Mono under windows with MonoDevelop.

I get a System.BadImageFormatException. I've tried doing a "./" before the library.so file, but nothing helps. I've checked and double checked that it's looking at the right directory and it is.

Is there something big I'm missing why I can't access this .so file under Windows/Mono?

+2  A: 

The problem is that the Linux SO is not a valid windows image. You will need to compile the C++ code under windows as a DLL and export the method so that you can call it using p/Invoke.

C/C++ is portable (mostly) at the source level, not at the binary level, so you cannot copy a Linux .so to Windows and expect that to be executable on the Windows platform. I am sure this raises the question, why can you copy your .NET/Mono dlls and exes from window to Linux and have them run, that is because the Mono CLI implmentation has code which is able to load the IL from the Windows image (PE) and then execute the loaded IL in the VM, so in this case it is not the native binary code that is being executed, but just the platform idependent IL which is loaded from the DLL/EXE container file.

Chris Taylor
+6  A: 

You can't use a .so elf binary on Windows for your native code. You need to recompile it into a native binary supported by Windows (namely a .dll).

I suggest you read our wiki page about cross platform interop between managed an unmanaged code.

Jb Evain
I was thinking it was something big like this. I was hoping that Mono somehow could get around this and it would just work. Guess not. Thanks for the link!
Nick
The thing is that Mono “surrenders control” to the underlying OS when it comes to P/Invokes, so there's no way to get around that.
Jb Evain