0

I'm working in VS 2019 on a C++ program in which I want to link into a bunch of 3rd party dlls, which are located in a folder separate from my executable. I don't want to copy all the dlls into the executable folder and have found the following solution.

Just like in the solution, I create a registry entry to define the keys with the information about the executable and the required path information to link to the DLLs:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MyExe.exe
    • %Path2MyExe%\MyExe.exe (default key)
    • Path = %Path2DLLs%

The compilation from within VS works fine and when I start the generated executables from outside VS by (a) double clicking or (b) by using the command line, the 3rd party DLLs are found and the program is executed as expected.

However, when I invoke the debugger from within Visual Studio (c), execution is halted right away complaining that DLLs cannot be found.

I have checked the present working directory from within the code using _getcwd and for all options (a-c) it indicates the same directory.

So the question is: why does option (c) - debugging from within VS - not work?!

Cheers, Sebastian

shoelz
  • 55
  • 4
  • 1
    Set your `PATH` environment variable in the debugging -> Environment setting. You can use $(Path) as a base. – drescherjm Dec 04 '20 at 17:02
  • OK, this did not work for me, but it got me on the right track (see my answer below). However, I'm not quite sure if I handled this right. – shoelz Dec 04 '20 at 17:54
  • I have successfully used that in a few test projects however for the most part I have `CMake` copy the dlls to the Debug and Release folder in my VS Project for me so it's not something I do often. – drescherjm Dec 04 '20 at 17:56
  • Yeah, I would think that should work, but for some reason it doesn't. I tried to set the path as follows: `set Path = $(MyDllPath);$(Path)` , which does evaluate to the correct paths but does not work when trying to debug. – shoelz Dec 04 '20 at 18:30

2 Answers2

1

It's probably because the executable that's launched when debugging is a vshost executable, not the generated executable for the project, and so it needs a separate entry in the registry.

If you want to stick with this kind of a build (highly not recommended), the easiest way to debug is to disable the hosting process:

enter image description here

Blindy
  • 65,249
  • 10
  • 91
  • 131
  • Also just to be clear, there's no such thing as "linking" to a DLL, unless you're talking about COM objects, and even then you're actually linking to the `.tlb` file automatically generated for you. You're "loading" a DLL. – Blindy Dec 04 '20 at 17:00
  • Hm, according to [this thread](https://stackoverflow.com/questions/42941258/disabling-visual-studio-hosting-process-on-visual-studio-community-2017) this host feature is not inlcuded in newer VS versions anymore and I cannot find the according setting. Also, I checked the executable name using `GetModuleFileName` and it is always the same. ... since a DLL is a dynamic link library (DLL) I would say that I'm dynamically linking into the library. – shoelz Dec 04 '20 at 17:23
0

Following the suggestion by drescherjm I tried to prepend the DLL directory to the PATH variable in "Configuration Properties -> Debugging -> Environment" following this solution.

However, this did not work for me. I also added the path directly in the system environment dialogue without success.

What did work in the end is setting the working directory under "Configuration Properties -> Debugging -> Working Directory" to point to the DLL folder. Now all three calling routes (a-c) work as expected.

Thanks to everyone for taking the time to help me out on this.

Sebastian

shoelz
  • 55
  • 4