0

Is C++ source code required to build a .NET wrapper or static libraries *.lib files are just enough?

We plan to use SWIG.

Thanks.

Stephen Kennedy
  • 20,585
  • 22
  • 95
  • 108
abenci
  • 8,422
  • 19
  • 69
  • 134
  • You need the libs and headers – Alan Birtles Oct 30 '19 at 07:35
  • Take a look at [this](https://stackoverflow.com/q/21005412/7869744) – blenderfreaky Oct 30 '19 at 08:19
  • I'm confused why you're asking - SWIG seems to do exactly what you're asking about - or do you mean you intend to somehow statically-link a C# program to SWIG itself? That's... weird. – Dai Oct 30 '19 at 08:32
  • 3
    You won't have much use for SWIG without .h file(s), surely you have them. Be careful a bit, you'll have to learn two things instead of just C++/CLI and we can tell that you're not up to speed on that from the way you tagged the question. If the unmanaged interface is relatively simple and stable then you don't need SWIG at all. Stable is pretty much implied if you only have a .lib file. And be careful with that static .lib file, it normally has to be built with the same toolset version you are using to avoid trouble. – Hans Passant Oct 30 '19 at 08:43

1 Answers1

2

w.r.t. your question asking specifically about static-libraries *.lib:

Is C++ source code required to build a .NET wrapper or static libraries *.lib files are just enough?

I doubt you actually intend to wrap a static-lib: Statically-linked libraries generally aren't redistributable nor portable (e.g. the authors of closed-source static libraries need to build them every time a new supported compiler comes out, e.g. you can't use a GCC lib with VisualC++ 2017, and an x64 VisualC++ 2017 lib won't be compatible with an x86 VisualC++ 2015 project) - and even if you loaded a *.lib into your process' memory and jumped into a known function address inside the lib's image, it would immediately break because the static library's code will have references to certain memory addresses (e.g. of string-constants) which aren't yet relocated - you'll get an segfault (or "Access violation" on Windows) crash if you're lucky (if not, it'll definitely corrupt your process' memory space before being detected).

P/Invoke in .NET Framework and .NET on Windows (i.e. using [DllImport]) only supports DLLs (Dynamically Linked Libraries), not statically-linked libraries.

You can also call into native code if the native code is available as a COM object, or can be accessed through platform features like OLE, WMIC, ADSI, etc (assuming your code's process is the same ISA as the native code you want to call, as it will still be loaded into your process, which is why you can't use 64-bit Office Excel to open databases where only a 32-bit OLE-DB or ODBC driver is available).

When a library is available as a *.lib then you need to make your own native host first - a simple C/C++ Win32 (PE) EXE or DLL that re-exports all of the useful functions from that *.lib will be sufficient - because then those exports can be imported by C#/.NET.

But in general:

  • If you are exporting COM objects to .NET then you don't need both the source-code files (*.c, *.cpp) or header files (*.h and *.hpp), only the IDL files or *.tlb (Type-lib) which the compiler will generate for you.
  • If your native code is also available through other platform features like OLE, ActiveX, COM Automation (IDispatch), ODBC, OLE-DB, ADSI, WMI, etc then you wouldn't be using [DllImport], and those platforms all either provide a standard interface (like ODBC and OLE-DB)
  • But generally speaking, no - you do not need the source-code (i.e. both *.c and *.h files) to create a .NET wrapper around native code exported from a native DLL and imported into .NET using [DllImport].
    • But you will need the header files (*.h) from a C/C++ project in addition to knowing the compiler settings (for finding out things like calling-convention, parameter marshaling info, etc) and a PE inspector (to verify the exported functions are at least present in the DLL you want to load).
  • Don't forget to ensure you provide both x86 and x64 native DLLs for all functionality if you're compiling your C#/.NET code for AnyCPU (tip: Using a 32bit or 64bit dll in C# DllImport )
Dai
  • 141,631
  • 28
  • 261
  • 374