I have an executable which uses TBB. When debugging in Visual Studio 2022 the wrong TBB DLL is being loaded - the one from Visual Studio install, not the one I am using.
I've tried setting the PATH variable in launch.vs.json
"PATH": "c:/mytbb"
but I can see inside my debug process that VS is adding its path first
"PATH": "<install-dir>\\VC\\Tools\\MSVC\\14.34.31933\\bin\\Hostx64\\x64;c:/mytbb"
How would I force VS to load my TBB and/or disable it from adding its own search path first (last might be ok)
If you use LoadLibrary, you could use SetDllDirectory to add directories to the search path used to find application DLLs.
I think the easiest way is the method proposed by Hans, just replace it without considering the path.
Looks like there's isn't a good solution to this question, I'd call this a missing feature / issue in Visual Studio.
As suggested, you can copy the DLLs to your exe's directory but that's not a scalable solution for projects with multiple EXE's (think 200 EXEs referencing TBB - its quite a mess).
SetDLLDirectory isn't an option either as the DLL is loaded before the program executes.
Related
This question already has answers here:
How do I set the path to a DLL file in Visual Studio?
(7 answers)
Closed 7 years ago.
In Visual Studio 2010, under VC++ Directories > Executable Directories, I have specified the path to glew32d.dll. However, when I run the executable, it still complains.
On the other hand, if I copy the DLL into the local folder and run the executable then, it doesn't complain.
Can someone please tell me how to fix this? Also, why is Visual Studio not recognizing that path?
Update
Scenario: I currently use a template project which I use as a starter code for a lot of my projects. This template depends on glew32d.dll. I usually store all dependent dlls in a common bin folder. I was hoping to reference this folder and Visual studio could read the dlls from there, instead of me having to copy the dlls everytime. What would be a good way to handle this?
Specifying the path to the DLL file in your project's settings does not ensure that your application will find the DLL at run-time. You only told Visual Studio how to find the files it needs. That has nothing to do with how the program finds what it needs, once built.
Placing the DLL file into the same folder as the executable is by far the simplest solution. That's the default search path for dependencies, so you won't need to do anything special if you go that route.
To avoid having to do this manually each time, you can create a Post-Build Event for your project that will automatically copy the DLL into the appropriate directory after a build completes.
Alternatively, you could deploy the DLL to the Windows side-by-side cache, and add a manifest to your application that specifies the location.
I've experienced same problem with same lib, found a solution here on
SO:
Search MSDN for "How to: Set Environment Variables for Projects".
(It's Project>Properties>Configuration Properties>Debugging
"Environment" and "Merge Environment" properties for those who are in
a rush.)
The syntax is NAME=VALUE and macros can be used (for example,
$(OutDir)).
For example, to prepend C:\Windows\Temp to the PATH:
PATH=C:\WINDOWS\Temp;%PATH%
Similarly, to append $(TargetDir)\DLLS to the PATH:
PATH=%PATH%;$(TargetDir)\DLLS
(answered by Multicollinearity here: How do I set a path in visual studio?
try "configuration properties -> debugging -> environment" and set the PATH variable in run-time
To add to Oleg's answer:
I was able to find the DLL at runtime by appending Visual Studio's $(ExecutablePath) to the PATH environment variable in Configuration Properties->Debugging. This macro is exactly what's defined in the Configuration Properties->VC++ Directories->Executable Directories field*, so if you have that setup to point to any DLLs you need, simply adding this to your PATH makes finding the DLLs at runtime easy!
* I actually don't know if the $(ExecutablePath) macro uses the project's Executable Directories setting or the global Property Pages' Executable Directories setting. Since I have all of my libraries that I often use configured through the Property Pages, these directories show up as defaults for any new projects I create.
I have a Visual Studio 2008 project which uses libcurl.dll (dynamic linking on run-time). I want to update libcurl.dll to a newer version. I manually replaced the dll in the file system, cleaned and built the solution. But during debug, the project is not able to find libcurl.dll
Edit: The new dll was built with additional dependencies from libssh2. What all changes should I make in order to use the new DLL?
What is the correct way to upgrade a DLL in Visual Studio 2008?
Use Dependency Walker to find any DLL related issue.
Check if 32-bit/64-bit system path is causing problem.
Check if dependent DLL is causing any problem, or if DllMain of your DLL is returning failure.
DLLs are loaded the same way as executables. They should be either in the same directory or they should be accessible with %PATH%.
Follow these guidelines and VS will find it. Most likely you messed something else.
When you are replacing DLL there is no need to rebuild.
When you buid, the header and the .lib files are used. If you new DLL has the same entries, then you can simply replace the just te DLL file and restart the app.
If your new DLL has different entries or different types of params, then you need new headers, new .lib and then you need to rebuild.
The project runs okay in the debug mode of Visual Studio, but when I tried to double-click the exe generated, it says some dll is missing. When I copied the missing dll beside the exe and double-click again, no error message dialog appeared but also nothing happened(the project has Qt-based GUI and reference some external png files).
How does Visual Studio run the exe ? How can I run the exe on my own ? Should I create a installer for the project to make it run on other computers?
you would need to either build statically or provide the required dll files.
the page at http://www.tapkaa.com/2013/05/what-dll-files-are-required-to-run-an-application-developed-with-visual-c/ tells how you can find the missing dll files.
When a process needs to load a DLL by name (without a full path to it), it will check several different places. One of those places may be the current working directory. (The details of the search path are complicated by history and security issues. You can learn the details by looking up LoadLibrary and SetDllDirectory on MSDN.)
In Visual Studio, if you look at the Properties page for the project, and click the Debugging tab, you'll see what directory is set as the working directory when you launch the program from Visual Studio. When you double click on an icon, I believe the working directory will be the directory of the executable file. If these are different, that could explain why you're able to find the DLL in one case but not in the other.
If you're calling LoadLibrary directly, the best thing to do is to always give the full path to the library. Typically, you GetModuleFileName to find out the full path for the executable, then replace the filename portion with the name of the DLL or a relative path from the executable to the DLL.
If you're failing to load an implicitly-linked DLL, then you probably need to make sure your DLL is in the same directory as the executable file.
I'm trying to compile a SDL-program I've written, but when I do, this error shows up:
The program can't start because SDL.dll is missing from your computer.
Try reinstalling the program to fix this problem
I have no idea as to why. I have SDL.dll.
I have put it in the correct folder: C:\Windows\System32.
I have the correct PATHS to all the SDL headers and such as well.
VS says:
Build succeeded: 1
and THEN the error above pops up on screen.
Add it into your debug folder or whatever directory your program is currently located at.
SDL.dll has to either be in the same directory as your application, or in a directory that's in the PATH environment variable.
IfSDL.dll is 32-bit and you're running a 64-bit system you have to place the dll into /Windows/SysWOW64/ rather than /Windows/System32/, which is used for 64-bit dlls.
EDIT:
You probably shouldn't be deploying your DLLs by copying them into the System32 directory, unless they're common libraries that are used by several applications, and even then I would use discretion. For example, an application could update the DLL, which could break other applications that rely on an older version of the library.
Instead, copy the DLLs into the same directory that the executable is being built in. If you're building and executing with Visual Studio it will look for the DLL in the Project directory, where your source files are probably located.
Just place your SDL.dll in the same folder and your problem will be solved.
And to answer to your problem with the PATH, you can specify in visual studio where he will look for executables while debugging. Maybe this isn't set correctly and that's why VS can't find SDL.dll?
Let's assume my program needs several DLL's to work. I should provide that DLLs to the user in my distribution. For now I need QtCore4.DLL, QtGui4.DLL, msvcp90.DLL, msvcr90.DLL, mylib.DLL, Kernel32.DLL...
Would be nice if CMake could get full list of DLLs (or .SO) files. Then I would remove items like "Kernel32.DLL" from that list and copy the DLLs to my distribution.
I can't guarantee the next build will be done on the same version of the Visual Studio, so hard-coding paths like "C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT" or "E:\Qt\4.6.3" is not good for searching for the DLLs.
Thank you!
You can use Dependency Walker on windows (or the cmd-line dumpbin tool from visual studio). However this is not really a CMake solution and there is not really standard solution with Cmake.
There is, however, the InstallRequiredSystemLibraries module, which you can use to get the system dlls (msvc[r|p]90.dll with msvc and mingw10.dll with mingw).
As suggested by Andre there is InstallRequiredSystemLibraries for finding/installing the correct C/C++ runtime. There is also BundleUtilities that can be used to find the other dependencies of your application, library and/or plugins.
It can never pick things up like runtime loaded plugins, but you can add them along with the library directories that should be used. In the most recent versions of CMake quite a few improvements have been made to make BundleUtilities more reliable on all platforms.