Visual Studio 2019 doesn't find DLLs in the Executable Directory

Question

_{Sunday, July 21, 2019 1:20 PM}

I didn't have this problem in Visual Studio 2015 and 2017. I always put my DLL files in one of the Executable Directories (Project>Properties>VC++ Directories>Executable Directories) and it worked fine.

Now I'm using Visual Studio 2019 and whenever I try to run my project through Visual Studio, I get an error saying "The code execution cannot proceed because ______.dll was not found.", even though the DLL file is in one of the Executable Directories.

Is there any way to fix this? I don't want to put DLL files in the same directory as the .exe, because I want to have a project template that takes care of everything, so I don't have to manually copy DLL files every time I start a new project.

All replies (3)

_{Sunday, July 21, 2019 2:31 PM | 1 vote}

Instead of commingling your DLLs with binaries provided by VS, the Windows SDK, etc. you could place them in their own folder.  Add the path to the folder to the PATH environment variable.

_{Sunday, July 21, 2019 3:25 PM | 1 vote}

The thing is, when I get the Path environment variable from an executable started in 2017 and 2019 the paths that I get back are identical. It is the same as if I just open up a Command Prompt window and type echo %path%.

It is this path that Windows uses to load DLLs. The search order is listed in Dynamic-Link Library Search Order. Because Visual Studio obviously provides the same path regardless of version, then this means it isn't a Visual Studio problem.

I also wonder why you got the idea to do this anyway. The description in the Visual Studio properties is:

"Path to use when searching for executable files while building a VC++ project."

So it explicitly states that it is used only when it is building the project. Also, don't forget, if it did apply to debugging then you would have a difference in behaviour between running with and without a debugger.

Anyway, from everything I have seen with testing Visual Studio, unless you have been modifying the debugger environment then the only portion of the environment that you would have any kind of success placing DLLs in are the ones in the $(PATH) portion, since this corresponds to the system path. But since you only stated "one of the executable directories" then that doesn't mean anything.

One way to do this without requiring messing around with the system settings is to add a post build event to automatically copy the DLLs from a known directory on the system to the build's output directory. It is also easy to put this into a property sheet so that all you have to do is add a property sheet to any new projects.

This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

_{Thursday, July 25, 2019 1:55 AM}

Hi rokcej,

Did your issue solve? If you still have any doubts, please feel free to let us know. If the reply is helpful for you to solve the issue, please consider marking as answer.

Best Regards,

Perry

MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected]