I'm a bit confused as to what's happening here.
My understanding is that when an assembly is required at runtime, the runtime will first try to load the assembly from the executing directory (or the directory where the dependant executable is located). After which it will attempt to find the assembly within the GAC.
First of all, I am on Windows.
Now, when I'm compiling my solution is VS, everything works fine (as expected), but when I compile the same solution in MonoDevelop, the compilation stops due to errors pertaining to a missing log4net reference (the exact assembly for which I manually installed into the GAC to avoid this situation).
So, my question is this: Does MonoDevelop look at the GAC at compilation time to determine if an assembly is available, or is there another location in which I need to provide the required assembly?
Thank you for your help!
From MonoDevelop site:
I added an assembly to the GAC, why doesn't it appear in the assemblies list when I try to add a reference in a MonoDevelop project?
Bacause MonoDevelop does not look for assemblies in the GAC. On Mac
and Linux, MonoDevelop uses pkg-config to locate installed packages
and get the list of assemblies that each package provides. A package
specifies this list of assemblies in a .pc file which has to be
installed in the standard pkg-config directory.
If you are developing a library, MonoDevelop can automatically
generate a .pc file for your project (in the project options dialog,
select "Linux Deployment Settings", and check the "Generate .pc file"
option).
When targetting .NET on Windows, MonoDevelop uses the same
AssemblyFolders mechamisn that VS uses.
Related
I just built the project that I'm supposed to fix. I double checked that correct DLLs are loaded - the project uses Qt 5.3.0, and the dlls are loaded from 5.3.0 directory. I am not sure where is the problem. Is my project using incorrect Qt headers? Or is the DLL build incorrectly?
I'm building in Debug with Visual Studio 2017. The DLLs are also built with visual studio. I tried Vidual Studio 2010 instead, since it's 2010 project, but the error was the same.
Are you in release or debug mode? QtCoded.dll is related to debug profile.
Another explanation could be how your Qt was built.
If I remember correctly Qt was built with msvc2015 so you have to use msvc2015 to build your exe with Visual Studio and it is not possible to use a msvc version before or after that.
Please remeber that you can't use the Qt framework built with mingw with msvc.
In other words I suggest you to check which version of msvc are you using with Visual Studio and which version of Qt framework.
Regards.
In my case, the problem was following:
One of the sub-projects was accidentally configured to use Qt 5.6.1, whereas the rest of the solution used 5.3.0. I found out by opening the result binary in dependency walker.
I just had the same problem with QT 4.
The solution was found on this post: The procedure entry point could not be found
I ran into the same problem, and in my case, this was due to the fact that I had two versions of the same library installed on my computer.
In the end, the problem was that I was linking my program against the new LIB file while my PATH was pointing to the old DLL. When the library version number is not included in the LIB or DLL file names, it is very easy to mix the versions.
I my case I was using a QtCored4.dll and others from an older version of QT. The solution was copy the DLLs directly from my QT installation directory which was used to build the application (as it was set by my QTDIR environment variable): C:\Qt\4.8.7\bin to my application directory.
Recently I switched from mingw to msvc compiler for my Qt app.
I am using Qt5.8. The msvc debugger is from the windows 10 kit (though I develop on Win7 and Win8.1) and the compiler from the vc++2015 build tools.
I can run the app locally, but I can't run it on a different, clean computer.
I know that I have to copy the compiler specific dll's to the application's executable directory. All the other dlls are found by windeployqt. Still I don't get it to work. I can't ship vc_redist packages the user has to install, due to the requirement to be able to load the app from a pendrive. On the dev machine there are several dlls of the same name, how can I figure out which ones are actually used by the compiled app?
Questionable dlls is especially api-ms-win-crt-runtime-l1-1-0.dll.
On the deployment I got those errors:
I also tried Dependency Walker and showed the full paths. I assume the first hierarchy level is the important one, that's why I've hidden deeper hierarchies. I am wondering why the full path shows the dir System32 because isn't this the 64-bit files folder?? I did not target any specific one but my app must be running on x86. Is this a misunderstanding?
EDIT
According to another question and this Microsoft blog update it worked for me when I additionally included all dlls from this folder C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86. There is also a file named ucrtbase.dll. I have no idea why DependencyWalker showed different ones.
You can use tools such as Dependency Walker to see which DLL is used by any other DLL or exe file.
Edit: You can also take a look at Determining Which DLLs to Redistribute on MSDN
Also you could use static linkage to link against the MSVC runtime (i.e use /MT switch instead of /MD (see https://msdn.microsoft.com/en-US/library/2kzt1wy3.aspx). However this would also mean rebuilding Qt, but it would also give you the opportunity to build a static version of Qt, meaning that you would not need to ship any DLL alongside your exe. You can find more info on Qt wiki: Build Standalone Qt Application for Windows
After reinstalling Visual Studio 2010, I recompiled the code and encountered the following error:
Error 'LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt'
A solution mentioned that the lib file is incompatible and I need to install Visual Studio 2010 SP1. I did that, and now it has been solved.
I am wondering how can I check whether a lib file is created by SP1 or not?
I tried dumpbin, but I cannot find the version in its result.
It was not an incompatibility with your LIB file that caused the problem here, so checking the version of the linker that created it would not be a solution anyway.
The issue is that cvtres.exe (used internally by the linker toolchain) depends on a particular DLL (msvcr100_clr0400.dll) shipped with VS 2010 RTM. When you update to a later version of the .NET Framework (e.g., by installing .NET 4.5 or installing a later version of VS), this DLL is replaced. That stops cvtres.exe from working.
The reason why installing VS 2010 SP1 fixes it is because it actually modifies the cvtres.exe application to break the dependency. And now that all pieces of the linker toolchain work, you can compile and link the code without error.
Of course, there are other problems you can have when you start mixing libraries created by different versions of the compiler and/or linker. They aren't guaranteed to create 100% compatible output, so mixing them is not supported (at least not between major versions, I'm uncertain about how this rule applies to service packs).
In general, it's best to just recompile all libraries whenever you update your build system. The only time you wouldn't do this is if you didn't have the source code, in which case, you need to be very careful about updating your build system, lest you introduce gratuitous incompatibilities.
As far as determining the version of the linker that prepared a particular binary, using dumpbin.exe (included with the SDK) is exactly the correct approach. For static libraries, run the following command from the Visual Studio SDK Command Prompt:
dumpbin /rawdata:1 MyLibrary.lib
You'll see the assembly manifest, which will include the full path to the compiler used to build the library as well as the version of the CRT that it depends upon.
For dynamic libraries (i.e., DLLs) and executables, run the following command:
dumpbin /headers MyApp.exe
Look under the "Optional Header Values" section (not actually optional) for the version of the linker, along with a timestamp of when it was generated.
Note that you're very unlikely to find this information in release builds of a library or binary.
I'm not a a very experienced Windows developer, so I hope this all makes sense.
I created a Managed Assembly DLL using Visual Studio 2010. The DLL (Plip.dll) contains a C++ class that is using System.IO.SerialPort class to do some simple communication over a serial port.
In a second Visual Studio project I created a simple GUI that uses the class found in Plip.dll. In my GUI project I have the line : #using "Plip.dll" . In the Project Properties I set the 'Resolve #using References' value to the correct location of Plip.dll. The GUI builds just fine. If I copy the GUI.exe and Plip.dll to the same folder, the GUI runs just fine on my computer.
The problem I am having is that when I copy both files to a second computer, I cannot get the GUI executable to run. I get the following error : "System.IO.FileNotFoundException. Could not load file or assembly "Plip.dll" Vesion=.... ". I get this error even though both the exe and dll are located in the same folder.
Any suggestions on how to resolve this issue? Is there some option I need to set in my GUI project to load the DLL correctly at run time?
I suppose the problem is not the Plip.dll, but it's dependencies.
Use Dependency Walker on the second computer to see if it needs any other dll's (they might be installed in System folder or in %PATH% on your development computer, but not on the other).
If this second computer doesn't have Visual Studio installed, you are probably missing Microsoft Visual C++ 2010 Redistributable Package (you need to install it on the other computer)
Also make sure that you compile in Release because debug builds need debug dependencies.
I found the answer to this problem to be much simpler than Dependency Walker (but admittedly, that was fun to look at).
In my case, the issue was a mis-match between the .DotNet versions in the DLL and with the application's .net version. This was caused by building the "class library" using .DotNet 6.0 (dot net core?).
Instead, the entire class needed to be re-built using "Class Library (.NET Framework)"
enter image description here
I wrote an article on this problem.
https://keyliner.blogspot.com/2022/09/visual-studio-c-linked-dll-exception.html
Can someone link me a good guide for using libraries in a c or c++ project?
Right now I'm trying to add OpenCV to a newly created project. I've added all the directories I can think of in "Project and Solutions -> VC++ Directories" and to make sure I've dragged and dropped all the .lib and .dll files into the project.
The project builds but when I run the simple "Hello, World program" it gives me this error message:
"cv.exe unable to locate component.
This application has failed to start because cv200.dll was not found. Re-installing the application may fix this problem."
How can I really add this cv200.dll? I've dragged&dropped it into the project..
Thanks!
You need to make sure that cv200.dll is in the DLL search path at run time. The easiest way to do this is to put it in the same directory as the built executable. Dragging and dropping a DLL or LIB file into your project has no effect.
MSDN has a good description of the full DLL search order when loading libraries at runtime.
By default during installation OpenCV create env. variable path \bin.
All dll assumed to be in that dir. However you are using OpenCV 2.0, and OpenCV 2.0 installation doesn't include lib and dll files for Visual Studio. You seems already built all dll's and lib's. If you installed OpenCV correctly just move all dll's into \bin (for example C:\Program Files\OpenCV\bin)
If for some reason you are missing some dll or libs here is instruction how to build them
http://mirror2image.wordpress.com/2009/10/20/switching-to-opencv-2-0-with-vs2005/