I have a python project that calls a c++ wrapper dll that calls a c# com interop dll.
In my computer, with all frameworks and programs installed, my project runs very well.
But in a computer that just got formatted it doesn't.
I allready installed c++ 2008 redistribute and the c++ part is working but when I call a function from it (that will call the c# correspondent one), it gives an error.
I want to know what are the dll dependencies from both c++ and c# dll's to see what is missing :)
Looks like you need Dependency Walker.
Dependency Walker (a.k.a. depends.exe) works for both native DLLs and managed DLLs.
It is included in some Visual Studio versions, and can also be downloaded here.
Related
I have a .Net add-in and within this I have referenced a DLL I have made in C++/CLI. The DLL was designed against the OpenCV API - so now my .Net application can take advantage of the cool graphics capabilities offered by OpenCV.
The problem occurs when I deploy my add-in to other computers. When the user enacts a part of the program that specifically calls upon my C++ DLL it complains about missing the reference:
I suspect the code does not actually know where the DLLs are located but within my dev environment everything (obviously) works as I will have my environment set up different to your standard build PC.
What am I missing here ?
How can I successfully call DLLs created in C++ from a C# add-in? Bearing in mind add-ins are supposed to simplify the customisation of software like Office etc. This is very important - I have to be able to roll in non-.Net DLLs into my project and my code be able to find them.
My dll is just a plain dll, not a COM compatible dll (maybe it should be?) or should I be decorating my C++ code with __declspec(dllexport) a la https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-declspec-dllexport?view=vs-2017
So 2 things
Use Dependancy Walker to identify any dependancies on your dll and the dlls it uses further down the 'tree' hieracrchy. I found 2 that were missing and it wasn't obvious without this useful tool. Don't be overwhelmed with the results it gives you, just take notice of the missing dlls it's complaining about.
Make sure your dll is referenced within your project and not outside of it in some other folder where you built it.
This fixed my problem - in general just make sure your dlls are on the same path as your executable.
I have a C++ project, created in Visual Studio 2010, which needs to execute code from a C# DLL. I have done so using the
#import "pathname\filename.tlb" raw_interfaces_only
directive, as well as the CoInitialize(NULL) and CoUninitialize() COM calls.
The C# DLL was compiled in VS2012, and targeted .NET 4.5.
I was able to compile and run the project, and it seemed as though everything was fine, but we were noticing differences in some function calls. This was verified by loading the exact same C++ project into VS 2012, turning on /clr in Configuration Properties, and changing the Targeted Framework (of the C++ project) to v4.5 by modifying the .vcxproj file in Notepad.
So, I guess my questions are:
Why does a C++ project need to target a .NET framework? Shouldn't the C# DLL be able to handle that by itself? (Answered by Hans Passant)
Why is it possible to run a C#.NET v4.5 DLL through C++ with /clr off, and not have any warnings that it might not work? (Answered by Hans Passant)
Why do I even get results back from the function call? How is it possible that the C# DLL "works" (returns coherent results) at all? Why does it return different values when targeting .NET v4.0?
Is it possible to use the C# DLL from the C++ code, while still using VS 2010? Or do I need to switch the project to VS 2012?
Thanks in advance.
A native C++ project does not target the .NET Framework at all. The project creation wizard is a bit clumsy, it does not hide the combobox when you create the C++ project.
What framework version the C# DLL needs is established when you register it. Either done automatically when you tick the "Register for COM interop" build setting or explicitly by running Regasm.exe.
That native C++ code can call C# code without trouble is just a goody you get from using COM. Whose basic purpose is to provide the contracts and the glue to allow one language to call code written in another. The CLR has very good COM support and makes it look very easy. That's not the case for C++, writing COM client code is generally unpleasant due to the verbosity and it is pretty easy to make mistakes. Using raw_interfaces_only is a mistake, you don't get the benefit of memory management with smart pointers and error handling with exceptions.
I have a dll created in VC++ and visual studio 2005 now i want to add same dll in my C# application and VS2010.
But whenever i tried it gives me erro
"a reference to "../name.dll"could not be added please make sure that the file is accessible and that it is a valid assembly or com component"
Seems like C++ dll is native dll (and not managed C++/CLI)
You need to look at P/Invoke.
Platform Invoke Tutorial
DLL Import
I am trying to import a few DLLs that have been compiled for 1c2 machine (thumb) into a WinMobile 6.1 C# Smart Device project.
However when i try to import them to my C# project I get "A reference to ... cannot be added", I can add DLLs that have been compiled for 14C machine (x86), my C# WinMobile project has Any CPU as it's setting, is it possible to import 1C2 machine DLLs or do I need these to be recompiled to 14C machine x86?
You can't do what you're trying to do. You can't just "add a reference" to a native DLL from managed code. "Add Reference" is specifically for adding managed references.
If you want to call your native DLL from managed code, you must write and call P/Invoke interop functions. Even then, you can only call publicly exported C functions (not C++, unless it has a COM interface), so you may also have to write C stubs, or some form of factory functions to proxy any C++ calls you wish to make.
I have perhaps a silly question:
We have a VC++ COM DLL (developed internally) and we have ported our main app to C# and used COM Interop, reg-free to access the COM dll. Everything works just fine with internal embedded manifest.
However, the friendly product-dev/marketing/sales want to minimize the package and include the COM dll directly. Somehow, someone became convinced that the app distro should include the exe only (since it's unmanaged we can't just ILMerge it in).
Since we have the tlb/lib of the COM, could we somehow statically link it, without porting the whole COM to C# managed re-work?
Thank you
P.S. Pardon my wording: the company was downsized and I am the Python guy who had to learn everything .NET in the last week or so since now I am doing my job and the job of 2 ex-senior .net developers
It looks like Costura can more or less do this.
https://github.com/Fody/Costura
It specifically has support for merging unmanaged assemblies (ie a C++ DLL) into a .NET assembly.
Note - this is not true static linking but would achieve the aim of packaging everything in the single EXE to be distributed.
It is possible to include the source for the COM DLL into the project for the exe, or you could change the COM DLL project into a static lib project. Once you've accomplished that, you must modify the code to create the COM objects directly. All said, neither options are particularly easy.
Alternatively you could look into products like Spoon Studio that would allow you to wrap your exe and COM DLL into one exe without any code.