Is C++ source code required to build a .NET wrapper or static libraries *.lib files are just enough?
We plan to use SWIG.
Thanks.
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 )
Related
I'm writing a program for embedded linux on an ARM processor in .net that uses mono to execute. I have found that I can simply compile to either x86 or x64 architecture on my PC, copy the Debug directory over to linux, and run the program using mono myProgram.exe. The program is working perfectly like this and mono seems to take care of the architecture mismatch. This was true until today when I tried to incorporate an external native DLL.
I have both an x86 and x64 bit architecture of the external DLL and both work on the desktop environment fine. I have a shim class that uses [DllImport] to load the extern functions. However, when I try this on embedded linux with Mono I am getting a BadImageFormat exception. My guess is that Mono somehow transitions the compiled DLLs in the exe at start up but doesn't do the same for the external.
Some other info:
1. I don't have source for the native external library. I have x86, x64, and a .so library.
2. I have tried making a manage C++ shim that accesses the .so but can't get it to compile on the desktop since windows doesn't recognize the .so file.
Some thoughts:
1. Is there a way to embed the native DLL into a managed so that Mono will transition the native DLL too?
2. Can I link the .so file to a managed C++ project?
3. Is there a way to tell Mono to incorporate that Dll during execution?
Ultimately I'm looking for a solution that is wrapped in the exe that allows me to simply run it like I did before and control the native system.
If you have all the .dll and .so files for Windows and Linux, you can probably use dll maps feature of Mono. (https://www.mono-project.com/docs/advanced/pinvoke/dllmap/) which are used to map Windows dll names to Linux so names.
.Net does not recognize this, but Mono does.
I've read many questions and answers indicating that if I want to link my C# project against native libraries, I can't use AnyCPU platform target but must make separate 32- and 64-bit builds, each linked against the native DLL of the appropriate bitness.
This makes me wonder how the .NET Framework assemblies themselves are, or at least appear to be, built for AnyCPU. That is, when adding a reference to my GUI application, why don't I have to pick the 32-bit or 64-bit version of System.Windows.Forms? I thought this might just be some Visual Studio magic that would resolve to the appropriate GAC subdirectory (GAC_32 or GAC_64), but I searched for System.Windows.Forms.dll in the GAC and found it in:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll
Note the "GAC_MSIL". So how does this DLL manage to wrap a native 32-bit API yet remain linkable in a 64-bit application? And why can't I use a similar strategy to make a single C# DLL that links against a native 32-bit library yet remains runnable in 64-bit mode?
Option 1: In GAC you may register 2 versions of assembly one 32 and one 64 bit with exactly same names. Oracle DB Driver for .NET uses this strategy.
Option 2: With your assembly that will be AnyCPU deploy two versions of native DLL and choose proper DLL at runtime (SQLite works like that). As it turns out .NET Framework is intelligent enough to load proper version of native DLL via P/Invoke (Using a 32bit or 64bit dll in C# DllImport)
I had the same problem and ended up using Fody Costura
DLL Files will be shipped as embedded ressources and the lib takes care of the bitness.
You could find an example for SQLite here
The problem I have encountered was that your application needs to have access to the Windows Temp folder to create the assemblies from the ressource. If you dont need it, you could disable it using a config setting createtemporaryassemblies
On a .NET project, I have a couple of functions imported from native DLLs.
Currently to add the native DLLs to the project, they are copied to the root of the C# project and their property Build action is set to Copy to output directory.
Is there a better workflow for bundling native DLLs?
One option, which is particularly useful if you want single exe deployment, is to embed the DLL(s) into your manifest as Resources. This is a similar approach to what is often used to create "universal binaries" which can run on either X86 or X64 platforms from a single file. In that case you embed the 64-bit version inside the 32-bit version and extract it at runtime when needed. You can see that in action with the Sysinternals binaries.
In your case, you would embed a native binary within the managed executable, then either load it as an IO stream at runtime or extract it and reference it from the extracted path. In either case, you never have to worry about "losing" the resource because it's part of your project.
If you decide to go that route, the answer to how to do it has been provided several times over. Here's one such question:
Embedding unmanaged dll into a managed C# dll
I want to use c++ library in a c# project. Is there any wrapper tool to import all classes automatically?
SWIG can help create a wrapper consisting of two parts, one C++ sided, and one C# sided.
It needs a bit of work to set up the correct generation files though.
An alternative that requires more manual coding is C++/CLI.
For pure c apis I prefer p/invoke over either of them. There is a program to automate conversion of c headers. If I recall correctly it's called something like "P/Invoke Interop Assistant" or "Interop Signature Toolkit".
There is also mono/cxxi which looks pretty cool.
The procedure of using native .dll's in .Net is called P/Invoke. Look at http://pinvoke.net/ for some examples.
Note that you must match the build target with the version of the .dll. So for x86 .dll's you need to lock your project to x86, same with x64.
Note2 that you only need to lock the executing project (.EXE), not any additional projects loaded from the .EXE. .Net will automatically match .Net .dll's to CPU target type if they are set to ANY.
From http://social.msdn.microsoft.com/forums/en-US/clr/thread/c957959e-0f0c-422e-a5be-4ccfdd12e63d: You can use "dumpbin /exports <name_of_your_dll>" or dependency walker (depends.exe) to look at the exported symbols. They are both included in Visual Studio.
Additional comment on C++: While it is relatively simple to use native .dll's written in C from .Net, using C++ binaries that make use of objects is not as trivial. One way to solve that is to use a C++ CLI project a binding between managed .Net code and unmanaged C++ library.
If this is unmanaged code then you could use P/Invoke. Another possibility is to use the C++/CLI extensions to compile the code into a managed assembly that you could directly use.
There's a program written entirely in C# that targets .NET Framework 2.0.
Is there a way I could somehow compile (translate) managed EXE to a native one so it could be .NET-agnostic? I know there are probably commercial products for that purpose... but they are a bit expensive.
The problem is that we are to deploy the program on computers running Windows XP with no .NET Framework installed. There's also a requirement that the program's size must not exceed 500Kb (1Mb maximum) for it is downloaded from the web server (now the size is 255Kb). That is why there's no way we could attach a full-fledged .NET FX (or even a reduced one) to the downloaded program's file.
Obviously it is a terrible software engineering error that should have been detected and avoided earlier so we could use native technologies like C++ instead.
We have tried for now Novell's Mono - an open-source implementation of .NET Framework for Linux, MAC and Windows. Mono consists of C# Compiler, IDE, runtime (CLR) and Class Library assemblies (like System.dll and mscorlib.dll - much like .NET's class library assemblies installed to GAC).
What we tried to do is to locate CLR files and ship those along with our program's file and a few assemblies. This way the program can be invoked by running "mono program.exe" (command prompt) on a user's computer.
In addition to the inconvenience of such a use for the end user CLR files (mono.exe and mono.dll) turned out to be about 2.5 Mb in total that is much greater than the desired 500 Kb or even 1 Mb.
So, we have left with no other option but to translate our .NET App to a native one by a compiler, however the question remains - what compiler should we use and where could we find one...
For now I have stumbled upon a Singularity OS Project by Microsoft Research. It is an open-source research OS that is written in managed code (in part at least). The Singularity OS includes a Bartok compiler that the OS uses in order to translate a managed program to a native one (x86 32 bit). It should be noted that Bartok can't translate all the aspects of .NET 2.0 to a native code, but most of them. However I haven't yet learnt how to use the Singularity...
I would be really grateful to you if you could provide me with some useful tips and advice regarding the problem, your own experience with Singularity OS and Bartok Compiler or another approaches to the problem that I have overlooked and ways of solving it.
Thank you very much in advance!
Finally, using Mono's Full AOT feature (on Callum Rogers' advice) I've managed to produce a program.exe.dll that lacks a CLI header.
So it looks to me like a native dll. However I can't figure out how to convert that dll into exe or make it operational.
Also this dll doesn't seem to expose any functions of interest such as main function.
Check out AOT (Ahead Of Time) Compilation from the Mono project. This compiles your managed project into a native exe or an elf executable (depending on which system you target) that does not need the JIT. This is the technique used to get mono apps onto the iPhone (where the JIT/Framework are not allowed) and also has the added benefits of faster startup times, lower memory usage and it makes it harder for people to decompile your code. You said you were already using Mono, so it should be compatible.
Read up about it at the mono-project.com website and at Miguel de Icaza's blog (and iPhone info).
Note that you cannot use dynamic code or generic interfaces like
interface IFoo<T> {
...
void SomeMethod ();
}
And you will have to compile the DLLs of all the libraries you use.
PS: Make sure to use "Full" AOT for your problem.
2018 Update
At Build 2018, Microsoft announced .Net Core 3.0 roadmap that support Windows desktop applications (Winform & WPF)
2017 Update
For console apps, you can use .net core Self-contained deployments (SCD). Even for a hello world app, your package will 50MB+. You still need to install VC runtime though.
Update
As #jenix's comment, .NET Native is only for Windows Store Apps(UWP). After 3 years of it's announcement, this is still true, .net native for desktop may be dropped by microsoft . So this answer is not applicable anymore.
========
Microsoft Announced .NET Native Preview on Build 2014
With the .NET Native Developer Preview, apps will get deployed on end-user devices as fully self-contained natively compiled code, and will not have a dependency on the .NET Framework on the target device/machine. So, no .NET framework required on the target machine with .NET Native.
Announcing .NET Native Preview
Microsoft .NET Native
There is a project called CrossNet that parses .Net Assemblies and generates unmanaged C++ code, that can be compiled in any standard compiler.
Not really a solution for .NET to native conversion, but maybe this helps: http://www.yoda.arachsys.com/csharp/faq/#framework.required
Not quite sure that there is much you can do besides painstakingly rewrite the application. To ease the already burdening process, you could disassemble the .NET application using something like Reflector (into Microsoft C++), and use that as a base to start and just replace managed C++ references with native ones.