I have unmanaged dll that I do from my c# dllImport and call to functions from this dll.
What i done now is to copy this dll to my Realese and Debuge folders , and dllImport i call to this dll without any path.
What is the right way?
How can I add this unmanaged dll to my project that is automaticly will be in my realsae and debug folders. ( I can't wimple done add refernce with this dll because it unmanaged dll ).
And witch path should I write on the path on dllImport.
What is the right way?
" copy this dll to my Realese and Debuge folders" works. you may try post build (in native c++ project) or pre build (in C# project)
Related
I have a c++ project compiled with /clr support(e.g. wrapper.dll). This project(wrapper.dll) is a wrapper between .Net enviroment and unmaged dll(e.g. noCode.dll), which inherits from. I dont have access to code of inherited dll(noCode.dll), but I can link it to my wraper (by noCode.lib and noCode.h files).
When I want to use my wraper(wrapper.dll) in c# project I reference it and have to copy my unmanaged dll(noCode.dll) to location of c# project execution.
Is it possible to merge c++ unmamaged dll(noCode.dll) to managed dll(wrapper.dll) to allow to use only one file by reference(noCodeWrapper.dll) in c# projects?
It is not possible to link DLL files together.
But you can add that nocode.LIB to your DLL and then you don't need [DllImport]. Since you have LIB and H files, you can call the "nocode" functions directly from your managed C++ code.
If you had access to noCode.dll source code you could integrate it with wrapper.dll. Otherwise merging DLL binaries is not a task that could give predictable results.
I am trying to reference a .Net DLL(call it B.dll), which basically is a wrapper for a .Net third party(call it C.dll), into c++ MFC project. I did create the tlb file for B.dll and am able to instantiate and call this within the MFC app.
At the moment all the dependencies, B.tlb, B.dll and C.dll, need to be in the bin
folder of the MFC application. What I want, and am struggling to do, is to put these three files in a sub folder of the MFC execution folder.
I tried setting the "privatePath" of the B.dll config file to a sub folder but as I understood it, it's not the B.dll "privatepath" that needs to be set but the MFC application(which obviously hasn't got any as far as I know, as it's not a .Net application)
Any help is appreciated.
You don't need to use COM (if you need it my answer is obsolet).
You can write your own C++/CLI wrapper DLL that has just exports a native interface. Than call you can this native wrapper and this wrapper again loads your .Net component directly and executes the code in it.
In this wrapper DLL you can add an ResolveEventHandler where you implement your own search (maybe in the subdirectory). Add this to your CurrentDomain->AssemblyResolve
With this trick you get around all this COM stuff, and you have full control were assemblies should be searched for that can't be loaded.
I have the solution from here
I have several Unmanaged C++ written lib files which I need to link to Managed C++ dll.
Then I need to invoke functions of this Managed C++ from C# application.
First step is OK - Managed C++ dll is created, I can see with ildasm that it exports functions I need. However when I try to call this function from my C#-written test app it says:
An unhandled exception of type 'System.IO.FileLoadException' occurred in Unknown Module.
A procedure imported by {MyManagedCPP.dll} could not be loaded.
This message goes from VS2010.
I made simple experiment - removed dependencies from all lib files in Managed C++ dll and rebuild it.
With this change it is OK - app starts, I can call functions of Managed C++ dll from C# test app.
Is it not possible by design to call managed c++ functions when dll has static linkage with lib files? Technical restriction? Or there is some workaround?
Thanks
You no doubt have an implicit dependency on a native DLL. It isn't clear from the question what DLL that might be. It could be msvcrxx.dll for example, a runtime support library for native C++ code. Which would be rather bad, you don't want to mix CRT versions. Such a missing DLL otherwise prevents the C++/CLI assembly from getting loaded, producing the FileLoadException.
If you have no idea what that DLL might be then you could use SysInternals' ProcMon utility. The trace will show you the program searching for the DLL and not finding it. If it is msvcrxx.dll then be sure to rebuild the .lib files using the same compiler version you used to build the C++/CLI assembly. If it is something else then make sure you copy that DLL to the build directory.
I want to create a dll in visual c#, and use it in win32 program (visual c++).
From what I understand, for adding dll file in Visual C++ , I need also .h file and .lib file, but when I create a class library in visual c# I only get dll file.
Is it possible to create a .h file and .lib file in visual c# ?
No, it's not possible. But here is what you can do to use a C# library in C++:
C++/CLI Wrapper (this allows you to have both managed and unmanaged code in the same source file. The managed portion can then call the C# code). Here you can find an example.
Host CLR (the CLR acts as a library that can be loaded and "hosted" by a process).
COM Interop (expose your .NET type as a COM interface and matching coclass which you can easily use from unmanaged C++).
This thread is also quite interesting!
You could use LoadLibrary and GetProcAddress to load the DLL dynamically and you wouldn't need to create the files you refer to. You can read more here.
I have a C# project A which uses a .net wrapper DLL and a native DLL. I add the .net wrapper DLL to the reference list of project A. Since the wrapper DLL only works with the native DLL when they are in the same folder, the native DLL should be copied to the output directory of project A. I achieve this by adding the native DLL as a content file under project A and set its copy action to copy if newer. This is fine.
If a C# project B has direct reference to project A, VS will copy all dependent files used by project A to the output directory of project B. This means the wrapper DLL and the native DLL will be copied to project B's output directory as well. This works fine as well.
Then I have yet another C# project C, which only directly refers to project B, not project A. It is interesting to see that VS will not copy the native DLL to the output directory of project C, which is what I intend to do otherwise when project C uses the functionality of project B and looks for the native DLL to work with the wrapper DLL, it won't find it.
Can someone explain why VS doesn't copy the native DLL　to the output directory of project C? What is the mechanism of copying chain-dependent files in VS? Many thanks.
Basically reference-chains don't propagate, and it is up to the topmost assembly (the exe, web-site, etc) to ensure that it has everything it needs, either locally or in (for example with managed dlls) the GAC. You will need to add the files to the exe/web-site as "copy to output".
Why not just add the native dll as a reference in project A? This will ensure that it'll always be included when other libraries use A.
Edit: Nevermind, this only works if the dll is a COM or .NET component.
Because there is not an explicit dependency in the project, the builder does not know that those need to be output with the known binaries. What you can do is create a post-build configuration to copy those DLLs to a build destination upon compilation. You can Google how to do that, here's one of the first results that explains how to do this:
http://visualstudiohacks.com/articles/general/customize-your-project-build-process/