I know that this was already discussed somewhere in here but I have not find question that I wanted, namely: I have a C++ application that uses a lot (more than 20 -30 ) DLLs. I have defined in my Visual Studio 2010 project that the .exe will be copied to the ProjectDir (so that everything is neat and clear) but when the .exe is standing in the ProjectDir alone it cannot access the DLLs stored in the bin..// whatever folder along with many other files.
Can I somehow point the DLL folder so that the application will know where they are located ? (and the <myapp>.exe.local folder thing does not work in my Windows 7)
first of all there is no need to copy your exe file to your project dir, whereever your .exe file is created when you are debuging your project the running dir would be your project dir. and after that when you are trying to import the dll if you look for it relatively windows first search for that dll in your running dir then then it checks if it can find the dll in the whatever directory defined system PATH variable, but if you check for a absolute address there will be no looking.
so the first trick is to set all your dll pathes abslote so that there will be no searching and dll are imported easily but there will be a lot of problems if you want to move your application to another computer (eg HINSTANCE hDLL = LoadLibrary(L"C:\\mydll.DLL");)
. second you can give your dll pathes relative to the running dir (not the application path, these 2 may differ) and you can also specify directory for that (eg. HINSTANCE hDLL LoadLibrary("..\\dlls\\mydll.dll")
You may set the PATH variable.
Here you can find where windows looks for dll: http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx
and here how to set the path in windows 7: http://geekswithblogs.net/renso/archive/2009/10/21/how-to-set-the-windows-path-in-windows-7.aspx
Related
I'm trying to set up SDL2 in C++ Visual Studio but when I run the code(just some starter code I copied) it pops up with an error box box that talks about "SDL2.dll cannot be found" I tried switching to x64 but that was no help. I can see that the dll is right next to the lib files but it just won't work.
Your problem is the lib folder is not a place that your OS will search for dependent dlls by default. To fix this you would have to help your OS find the dll. There are several methods you can use to tell your OS where to look. One is adding an entry to your PATH environment variable that contains the full path to the folder containing the dll.
This site can help with setting the PATH: https://www.computerhope.com/issues/ch000549.htm
As second method is to put the dll in the same folder as the executable.
By default your OS probably is using the safe search option described here:
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.***
I'm having trouble creating a texture which is in my DLL project's directory.
I'm doing
D3DXCreateTextureFromFile(Device, "Sprites/ExpandBlack.png", &BlackTexture);
but that doesn't seem to work. However if I do the whole path like:
D3DXCreateTextureFromFile(Device, "C:\\Users\\Home\\Documents\Visual Studio 2017\\Projects\\NO\\NO\\Sprites\\ExpandBlack.png", &BlackTexture);
it does work.
I also tried doing ../Sprites/ExpandBlack.png, ..\\Sprites\\ExpandBlack.png etc.
Any kind of help is appreciated.
This is where Sprites is located and it has to be "compiled" with the dll.
../Sprites/ExpandBlack.png, ..\\Sprites\\ExpandBlack.png and Sprites/ExpandBlack.png all refer to the same relative path.
Relative paths append to the process's working directory. DLLs use the same working directory.
To get a DLLs path see Get DLL path at runtime
Relative paths are relative to the current directory of the process. If it works when using a full path but doesn't work when using a relative path then obviously your relative path is not leading to where it should be leading. Most likely because the current directory of the process that's supposed to access that file is not what it should be.
Since we're talking about a DLL here, I suppose the problem is that when running the program that's actually using the DLL, that program is launched from a different location than the one the DLL project file is in. Most likely, because the project is located in a different directory than the DLL project. Visual Studio will by default use the directory in which the project file is located as the working directory for the process. You can change the working directory that Visual Studio will use in the project properties under "Debugging". Most likely, you will want your sprites located relative to the application that's using them rather than some DLL that the application is using. If these sprites are actually tied to the library and required by the library to function, on the other hand, then you may want to consider embedding the files into the library, e.g., as resources, or at least place these files relative to the library and access them based on the location of the DLL and not the current directory of the process that's using the DLL. To get the path of your DLL, see the answer linked in user2176127's answer…
I'm a beginner with building software using C++. In my project I link to DLLs and I keep them stored in the root folder. I do this because I want the project to be portable from one machine to another, and I also want the release builds to have dependence from installing things into system32 and what not.
The problem is all the DLLs in the root folder is messy, so I want to organize them into subfolders. But I can't do that because putting the DLL in a root subfolder instead of the root, you get errors. I think because the DLL is copied to the output at the wrong location, not where the exe is, but in a subfolder, just like the source structure. Am I right about that?
What is a solution that will allow me to have the project be still be copy-pastable/portable between machines?
Windows searches for DLLs in predefined locations (see Dynamic-Link Library Search Order). Subdirectories of the directory where the application resides are not part of the search order.
To implement your requirement, you will need to explicitly add the directories to the searched locations. This process consists of two steps:
Call AddDllDirectory for each directory you want searched, in addition to the default search locations on application startup.
By default, DLL imports are resolved prior to starting a process' primary thread. To allow your application to change the DLL search path, import resolution needs to be postponed. The easiest way to do this is by using the /DELAYLOAD (Delay Load Import) linker option (see Linker Support for Delay-Loaded DLLs for additional information).
While it is possible, to segregate DLLs into subdirectories, it is best to keep them all alongside the executable image.
If you put the DLLs into subfolders instead of keeping them in the same directory as the executable, you would either have to modify PATH environment variable in Windows to point to every subfolder, or use the DLLs in LoadLibrary+GetProcAddress way instead of linking them to the executable via import libs.
In C# I know there's a way to edit the assemble config file or something of that sort, but for C++ I have no clue how to make it so instead of having all my dll's in the root directory put into something like /libs or /bin/ folder and my exe will look there for the dll files?
If you're loading the DLL at runtime you can simply write hDll = LoadLibrary("subFolder\\test.dll");. At first Windows looks for the DLL in the directory your program is located. Therefore test.dll will be found in app_dir/subFolder/test.dll (app_dir = path of executable). Note that this also works if the current directory is different to app_dir.
Look at MSDN for more information about DLL searching.
Your EXE doesn't look for DLL files. That means it doesn't matter whether you're using C++ or C#. Visual Studio is even less relevant as it's not even present when your EXE runs.
Windows looks for DLLs. In your C# example, Windows uses the assembly manifest to guide the search. In your C++ example, you didn't add one, so Windows uses just the default paths. The solution is thus obvious: use a similar manifest.
In a Project of mine, I use a Delphi Application which dynamically loads a wrapper DLL (exporting C-Style functions) which in turn is statically link against a bunch of 3rd party DLLs.
It works fine on my test machines, but on my customers computer it failed to initialize with an error Message like "Couldn't find entrypoint _somefunction#4AKKZ in TMYlibrary.dll".
After some investigation with sysinternal's process monitor, I realized that Windows would look fror DLLs in windows/sytem32 first, so if a DLL named similar to my DLL was present in system32, windows would pick that one and try to find my function entry points in it - which would fail.
Do you know of a possiblity to change windows' DLL the searching behaviour?
Additional Information
[Update] The .exe file is located on the top level of the application's folder tree.
The Wrapper and the 3rd-party-DLLs ar e both located in the Subfolder /bin of my apps Folder
Dev platform is windows XP/7, using VS2008 for the dlll and Delphi 2010 for the application
I found another solution myself:
SetDllDirectory adds an additional search path to the list of locations to look at.
From http://msdn.microsoft.com/en-us/library/ms686203%28v=VS.85%29.aspx
After calling SetDllDirectory, the DLL search path is:
The directory from which the application loaded.
The directory specified by the lpPathName parameter.
The system directory. Use the GetSystemDirectory function to get the
path of this directory. The name of
this directory is System32.
The 16-bit system directory. There is no function that obtains the
path of this directory, but it is
searched. The name of this directory
is System.
The Windows directory. Use the GetWindowsDirectory function to get
the path of this directory.
The directories that are listed in the PATH environment variable.
(maybe i should do my googling before I post on SO ;)
Ship the DLL in your program's folder. (same as the exe file).
Then Windows should try your version first.