Develop Reference

Native dll version conflict in referenced .net assemblies

I need to reference two assemblies in my .NET program:
The first assembly, namely ILNumerics, directly references native hdf5.dll library (version 1.8.17) by mean of dllimport("hdf5.dll") platform invoke.
The second assembly, of my own, is a .net wrapper on top native matlab runtime libraries, but this native runtime also internally makes use of native hdf5.dll library (version 1.8.12) [required when working with hdf5 data from matlab side].
Note also that native hdf5.dll library also depends on hdf5_hl.dll and zlib.dll.
I have tried to keep only one version of hdf5.dll library and dependencies and also to set environment variable HDF5_DISABLE_VERSION_CHECK to 2 when starting my application but I can't escape from abrupt crash as I need to use hdf5 handling from both ILNumerics and Matlab runtime sides.
Is there a way I can cheat "dllimport("hdf5.dll")" in ILNumerics assembly to alias some other name ? Note, I don't have the sources, so i cannot hard recompile with dllimport("hdf5_1_8_17.dll"), same for matlab runtime library, I cannot changed anything in it (again third party + native code). What about, in case cheating hdf5.dll name in ILNumerics would be possible, the indirect reference to hdf5_hl.dll from hdf5.dll ?
I guess my only last option is to use load ILNumerics and Matlab runtime assemblies in different applications domains, but then this would be "hell" because I will need to serialize data when calling one or another assembly exposed routine, right ? (I have never worked with separate application domains)

(How) can I export a function from a .NET assembly without using C++/CLI?

I'm working on a C# component which consists of two DLLs:
A .DLL written in C++/CLI exporting a symbol; unfortunately, this DLL dynamically links against the CRT and there doesn't seem to be a way around that.
A C# assembly.
The C++/CLI DLL gets loaded and then loads the C# assembly (and forwards most calls to it). Is it possibly to simplify this scenario so that I export a symbol from the C# assembly right away?

You can export your functionallity from C# as a COM server this way it should be pretty easy to call it from C++ as you would do with any other non-C# COM object.

I ended up going for the solution described in http://www.codeproject.com/Articles/37675/Simple-Method-of-DLL-Export-without-C-CLI
The general approach is to have a dedicated attribute which is used to decorate the functions to be exported. After building the assembly, ildasm is used to disassemble it. The resulting IL is patch a little bit so that the previsouly decorated functions are exported, then the IL is assembled into an assembly again.

Accessing C# library from VC++ code

I have windows form application written in VC ++ . I want to change the button click in this app (WInform app in VC++) to hit a function written in C#.
What are the possible ways to do this.

Calling a C# assembly without compiling with C++/CLI is tricky. some of the ideas I've had:
a) Create a mixed-assembly wrapper dll (mixed assemblies contain both native code and managed code). Add a reference to your C# assembly, then create functions in your dll that call the C# code via C++/CLI, then define dll entrypoints ( __declspec(dllexport) ) for those functions. You can now link against the dll as it will provide a native interface that C++ can understand, while internally that dll can call your C# code.
( Afterthought: You can probably compile this to a .lib, that would be easier than a dll.)
Walkthrough: Creating and Using a Static Library
b) Use Mono to call the C# assembly. Mono has a C API which you can use to load and use managed assemblies without using c++/CLI. This is what I would do if C++/CLI is not an option.
Embedding Mono
c) If your function has a relatively simple input/output signature (no large objects, etc) you might consider compiling your C# function into an executable and use standard input/output to call the function. You'll have to carry input arguments and the output as text, though. Then make C++ start the executable and pass some input to it, and read the output.

How can I generate C# source code for a COM Interop library instead of an assembly?

When importing a COM library (either directly with tlbimp, or indirectly with visual studio add reference dialog,) is there a way to generate C# source code instead of a binary interop assembly, like Interop.Word.dll, for example?
UPD: Reflector is bad idea. Problem is that for the com interface is not only a signature, but the order of the members. Reflector this order is violated

I would go ahead and generate the interop assembly using TLBIMP, and the use Reflector to disassemble it. The interop assembly has no actual implementation code, as you will see. You can then just copy and paste the code (or the CoClasses and interfaces you need) into a new .cs file in your project.

You cannot generate C# directly, but if your real problem is that you have a need to tweak the interop library then you might have better luck using the CLR Interop team's custom TLBIMP tool on codeplex - it's pretty flexible and you have full source [to it.]
http://clrinterop.codeplex.com/releases/view/17579
Update: If you're really trying avoid shipping binaries, then you could feasibly integrate the above tool (in source format) into your project so that you generate this interop library at runtime. Result? No binaries to ship.

In general it cannot be done. C# does not support all possible constructs needed to create a working interop assembly. You cannot add e.g. attributes to return types or method parameters in C# although they are needed sometimes to help the marshaller to correctly translate some C++ types.
Yours,
Alois Kruas

How would i use a C++/CLI dll that wraps native code with multiple dependent libraries in C#?

I am wondering how I would go about correctly setting up a C++/CLI library that wraps native c++ code that has several dependencies. I have tried both statically and dynamically linking the native library to its dependent libraries with no luck.
The Managed C++/CLI dll builds just fine and can be added as a reference to a C# project. However when I attempt to use any of the defined classes i receive either a BadImageFormatException or FileNotFoundException depending how i linked. I believe I need to specify the dependent libraries in the CLI library so it is loaded in the manifest but I am unsure of the process. Also because i know it will come up, I have verified that all of the libraries involved are built on the x86 architecture.

I figured out the problem and everything is working correctly now. It was a combination of several incorrect things all happening together.
If anyone has the same issue, I resolved it by setting up the following:
1) The Boost libraries that were referenced (specifically boost_thread) needed to be compiled with BOOST_THREAD_USE_DLL preprocessor (other boost libraries may need BOOST_ALL_DYN_LINK to just dynamically link everything). This is apparently a common issue.
2) I verified that all dependencies were in system Path (like R Ubben reiterated)
3) I used the DependencyWalker (depends.exe from sourceforge) to analyze my compiled managed DLL. It turned out that the libpq.lib library being used actually referenced additional DLLs that were not included in the lib folder but in the bin folder. So that need to be added to the Path.
4) Part of my wrapper was using the #include header for lists. This forced my library to link against 2.0 framework dependent libraries. This was not compatible with my 4.0 client targeted C# application. This was only made known by parsing through the Warnings from compiling (previously hidden due to C++ generating too many..foolish i know). However this was resulting in a System.BadImageFormateException being thrown despite everything targeting the same x86 architecture.
Hope that helps anyone else who has the same problem. The BadImageFormateException and FileNotFoundException were entirly too vague and unhelpful.

You should make the C++ dll in release mode and use extern "C" for public static things.

I have gotten that error when the dependent libraries were not in the path. The wrapper library is found because of the reference, but the reference does not also take care of the dependent libraries. Try placing them explicitly where the program is executing.