I need to integrate this C# dll
in my C++ code. I want to call some functions written in C# from dll and the rest of code write in C++. What is the easiest and quickest way to do it? The program will be executed only on Windows.
There are basically two cases to call a .NET DLL from unmanaged code:
The .NET DLL exposes a COM interface. In this case, you can use COM from your C++ code.
The .NET DLL does not expose a COM interface. In this case, you have two possibilities (to make it simple):
2.a. host the CLR as described here: Loading the Common Language Runtime into a Process
2.b. write a piece of managed C++ code (another DLL - written in C++/CLI) to wrap the .NET DLL and expose 'old way' DLL exports to unmanaged clients.
I don't specifically know the sharpbox system, but it looks like it's pure .NET and does not expose COM interfaces, so 2.b might be the best way to do it (not so easy...). Maybe it has a REST/Web easier API you could use.
PS: you can also add exports to a .NET DLL. This is described here: Is is possible to export functions from a C# DLL like in VS C++? but it's kinda hacky.
Related
I have a third-party unmanaged DLL which was written in C++. This library contains a lot of classes with a lot of methods. The library is not COM-based; trying tlbimp just gets me the error that the DLL is not a valid type library.
I managed to use functionality from this DLL from managed C++ though, and writing a wrapper DLL which delegates everything to the unmanaged one and using it from C# works fine. However, the third-party DLL is big, so I would have to re-implement the whole interface by hand to delegate all functionality to the unmanaged DLL.
Is there a way to simplify this? What comes in mind first because I am coming from the JVM universe is reflection, but C++ does not support it.
I do not have the source code of the unmanaged DLL, only the DLL itself, its associated .lib and a bunch of header files. Functionality of this DLL is exported via __declspec(dllexport).
I have a Classic ASP website with vb6 dll's and all is ok with the world, but now I have some extra functionality that has been completed using c# into a COM DLL. In the dev environment this is working, but now I wish to move this DLL onto another machine.
My question is what is the best way to do this?
I have seen answers such as "add it to the GAC" or, "in needs a strong name", etc.
What happened to the good old regsvr32?
Regsvr32 is still relevant today but you can't use it with .NET, only native DLLs. .NET has a special way to register COM-types as we shall soon see.
Regsvr32 works by invoking the DllRegisterServer export. DllRegisterServer gives the library a chance to register COM classes; type libraries; interfaces etc. This export is not present in .dlls created by .NET which makes sense because they are not COM by default. You can easily see these differences if you open up a .NET or non-.NET .dll in Dependency Walker/Viewer.
Here's a native c++ ActiveX dll I made earlier (Note the DllRegisterServer export on the right):
And here is a managed .dll. (Note there are no exports let alone DllRegisterServer):
If you have marked your c# class as COM-visible then you can complete the COM-registration by invoking:
regasm assemblyFile[options]
Tell me more
This will place the necessary entries into the Windows Registry.
There is no need for the GAC because native COM clients (VB6) do not use the GAC
Ahead of Time Compilation or AOT is a feature of the Mono runtime code generator.
mono --aot program.exe
This will generate a file called "program.exe.so"
How can i load this shared object file in php script and access the class objects and methods. ?
Thanks
The native library still needs to be loaded inside an AppDomain (i.e. the Mono VM/runtime) in order to run, it is not a native library as such.
If you must I'd suggest looking at
whether php supports COM interop (I don't use php, but I'd reckon the chance exists). This would be good since you could use that and profit from OO interface exposure
Use Swig which has support for C# some time now
Alternatively, use mkbundle, and/or create a native shared library that embeds a Mono VM. The shared library wrrap around the C# interface using a "C" native API's.
The Phalanger project should be able to do this. You can compile your php code with mono and also integrate with .net from php.
I am developing a managed lib (using Microsoft Web Services) and I am
including it into a c++ project. The project doesn't use /clr option,
so when I include my library's header file VS2005 show me an error
saying I have to use /clr option. Doing this I have a incompatibility
with /EHs command line option (error D8016), but changing from EHs to
no exception handling not solving problem and keep showing me same error .
Any suggestion is welcome.
Thank you in advance.
If you have unmanaged C++ code and want to use managed code, you have a few options:
Change your unmanaged code to C++/CLI, by use of the /clr switch.
Write a C++/CLI wrapper library. It could DLL-export unmanaged functions which you call in your unmanaged code.
Skip the wrapper library and directly DLL-export unmanaged functions via this library.
You can't use a managed lib from an unmanaged c++ application. Since you add the /clr option, your c++ application becomes managed too (just for the record :) )
Here's what might help you: http://msdn.microsoft.com/en-us/library/ffkc918h.aspx - the restrictions of the /clr option.
It is possible to write managed c++ adapter, that will call the C# library, and call this adapter from unmanaged c++ program as you would usually call a normal c++ library. You will compile your adapter library with /clr and your main c++ program without /clr if for whatever reason you want to keep it unmanaged.
You can embed a mono environment and start an AppDomain. mono's runtime API will allow you to instantiate classes and call members on them. It will be clumsy, but is will work
http://www.mono-project.com/Embedding_Mono
Note that Mono is a full .Net 4.0 compliant CLR and it can work with the Microsoft core libraries on Windows.
On windows and Unix it can work with the Mono corlib/class libraries. There are areas not covered in Mono, but they seem to get sparse. You can use the MoMa tool to spot whether your application uses incompatible/incomplete APIs.
Or you can just use the Microsoft .NET framework, assuming you're on windows anyway!
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.