My application is built with C++/MFC and links dynamically with ImageMagick. I have to deploy 130 (!) ImageMagick DLLs alongside my files when installing the app!
I would like to have a single DLL for the entire ImageMagick library instead of 130. Any ideas for how to do that?
The DLL uses the serach path. Place the ImageMagick.DLL in one directory that is included in the PATH.
If that's not possible, you can change the PATH variable. Add a path to the directory where one instance of the DLL resides.
Hmm, nobody ever complains about having to run their code on an operating system that has three thousand DLLs. Deploying one DLL isn't any easier than deploying 130 of them. Your customer won't mind. Hacking a library whose source code changes so frequently is something you'll regret deeply some day.
Related
I'm having a difficult problem to solve. I'm having two Qt-based applications, first one is in the main folder and the second one is located in it's subdirectory (yes, I'm forced to have it this way). The issue I'm facing is that I have to deliver 5 exact the same DLL's files for each application. I wouldn't have problem with that, if they wouldn't weight so much (10 DLL files = 60~ MB). Which is, definately too much.
On my debug build I am able to set the PATH variable within Visual Studio settings, and I will be not able to do so on production machines.
Is there any way I could set one of those application to rely on DLL files located in subdirectory?
I don't know what kind of an installer you're using, but the dlls should be stored only once in the archive, and the files should be hard linked on installation. So it's a non-issue unless your installer is broken or the install script is.
We have .NET application which uses C++ library via [DllImport]. It works fine on many computers (thousands of customers) excepting 3 computers. All of them have Windows 10 installed (other Windows 10 platforms work fine).
The exception is:
System.DllNotFoundException: Unable to load DLL 'Helper.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
This dll places in the same folder as main executable file.
What already done to fix:
put DLL in system32 folder;
installed different version of vc redist;
run as administrator.
The result is the same.
Any ideas, guys?
Thanks in advance!
Don't put the DLL in the system directory. You aren't supposed to put files there. Put the DLL in the same directory as the executable.
If you do that and the system reports DllNotFoundException that means one of the DLL's dependencies could not be found. Next you need to find out what the dependencies are, and make sure that they are all met.
You can use a tool like Dependency Viewer to check the dependencies, but really the best way to do this is to go to the source. Either the documentation of the library if it is a third party library, or direct from the source code and compilation options if you have built the DLL yourself.
I have made an allegro simple game . But when I open the *.exe file on another computer it says that there are many missing .dll files . How can I make my game to run on other computers without Visual Studio and Allegro 5 library installed ?
Longer version of my comment:
When you created your application, it links to certain DLL's that exist on your computer. When you distribute your game, you will either need to ZIP the DLL's along with your .exe or package them using package creators and ship it.
The best way to find which DLL's your exe depends on will be to use a tool like Dependency Walker. You don't need to copy absolutely all DLL's that your EXE depends on. Only the ones that you see are in non-standard paths like ones that are not in C:\Windows\System32. That being said, you might need to copy some from C:\Windows\System32. You will need to find that out on your own.
To package them all as a setup, you can use package creators like InnoSetup or NSIS. Otherwise, create a script that ZIPs it all up for you. AFAIK, there is no easy way to get all DLL's required that are missing from the other persons' system. You'll need to find them out by trial and error. It is a pain, unfortunately.
If you downloaded the pre-built binaries, link against the static, monolithic, mt build of Allegro. You'll need to adjust your compiler settings to match (/MT) and add ALLEGRO_STATICLINK to your list of preprocessor definitions.
If you do that, then you only need to distribute your executable file and your resources (images, sounds, etc).
Note that you should have at least two configurations: Debug & Release. When working on your application, you should use the Debug configuration (linking against the regular debug Allegro library). When distributing your application, you should use the Release configuration.
My basic issue is this: my program (MyProgram.exe) has a dependency on a DLL from another program (OtherProgram), and I'm trying to avoid repackaging a new DLL every time OtherProgram updates. I'd like to have MyProgram.exe link in OtherProgram's DLL when it launches, but I'm not completely sure that Windows allows for this. So if there is some kind of workaround that would also be acceptable.
And just for some background, the platform is Windows 7 x64, and MyProgram.exe runs fine when I create a symlink in the MyProgram.exe project directory to the DLL in OtherProgram's install directory. When I try to run it without the symlink, I get the "program can't start because OtherProgramDLL.dll is missing from your computer" error.
Any advice or links to relevant info is greatly appreciated!
EDIT: Clarification: the DLL is not linked at compile-time, this issue crops up at runtime
There are two types of dynamic linking in the Windows world:
Load-Time linking is when a DLL is loaded automatically when your program starts up. Windows finds this DLL using a specific algorithm I'll discuss below.
Run-Time linking is when you specifically load a DLL by calling LoadLibrary in your code. Similar rules apply as to how the library is found, but you can specify a fully-qualified or relatively-qualified path to control the search.
In the case of Load-Time linking, MS recommends that your program's DLLs are stored in and loaded from the same directory where your application is loaded from. If this is at all workable, this is probably your best option.
If that doesn't work, there are several other options, outlined here. One is to leverage the search order by putting the DLL in either the working directory or the directory where the application was loaded from.
You can change the working directory of an application by:
Create a shortcut to your application.
Bring up the shortcut's properties
Edit the "Start in" property with the directory where the DLL is located.
When you launch your application using the shortcut, it will load the right DLL.
Other options for load-time linking include:
Adding a manifest to your application which specifies where your dependent assemblies are, or,
Setting the PATH.
You could use LoadLibrary, but you would need a way to guarantee the DLL's location. This Wikipedia article provides good example on how to use the DLL after it has been loaded.
You can add the directory where the dll is located to the PATH environment variable.
I have struggled with the same problem and also found a dead end with the suggested methods like LoadLibrary, SetDllDirectory, Qt's addLibraryPath and others. Regardless of what I tried, the problem still remained that the application checked the libraries (and didn't find them) before actually running the code, so any code solution was bound to fail.
I almost got desperate, but then discovered an extremely easy approach which might also be helpful in cases like yours: Use a batch file! (or a similar loader before the actual application)
A Windows batch file for such a purpose could look like this:
#echo off
PATH=%PATH%;<PATH_TO_YOUR_LIB>
<PATH_TO_YOUR_APP_EXE>
/edit: Just saw #SirDarius comment in Luchian's answer which describes that way, so just take my batch code bit as a reference and all credits go to him.
I have the same problem with one application I am working on.
I do not want to use runtime loading because there are tens of functions I would need to manually create function pointer for.
Mr Dibling's mention of manifest file opened a new door for me but I sadly found out that the oldest version of windows that supports the feature is Windows 7. It won't even work on Vista.
Long story short, a friend familiar with Windows Application development told me to look up Delay-Loaded DLL, which turns out to solve the problem perfectly with minimal effort. It delays the loading of DLL library to either the point you manually do, or the first time its function is called. So you just need to add your DLL path to the search path before that happens, where SetDllDirectory helps.
Here is the steps to make it work:
1) Specify the DLL to be delay-loaded to linker, either through your makefile, cmake or VS property page (Linker->Input of VS2015)
2) Call SetDllDirectory at the beginning of your program, before any call to the DLL is made.
Delay-loaded DLL is supported all the way back to VC6.
SetDllDirectory is supported after XP SP1.
Use Symbolic Links to the 3rd Party Executables
I found the approach advocated by Aaron Margosis useful. See:
Using NTFS Junctions to Fix Application Compatibility Issues on 64-bit Editions of Windows
Essentially, create symbolic links to each of the dependent 3rd Party executables. Place these symbolic link files in and amongst your own dependent executable files. Except for filename changes to the targets, the 'soft' symbolic links will resolve the load-time dependencies even as the target of the links are changed by future updates.
I have compiled my Qt application and now have the following question - now my built project requires QtCore4.dll and QtGui4.dll to be located at the same folder where the .exe file is. (I built my project using MSVS2008 with Qt addon)
Q:
Is there any way to combine my final application with these .dll files so that they make one large .exe-file? (I simply don't want to have another bunch of dll files with my release - app)
Thank you.
You need to build and link to Qt statically.
Edit: Here's an updated link to at least similar information.
Bundle them into a self-extracting .exe (e.g. using 7zip) which extracts all files to a temporary directory, runs the program, then deletes the files after the program exits.
This will be easier, less time consuming and less legally constraining than statically linking Qt as previously suggested.
Of course you could statically link someway. But the point of using DLL should be to make program smaller (both on disk and in memory, if other apps are using Qt libs of course)... DLL such as those should be systemwide so that other apps needing them can use them. Basically you have to say to people wanting your program to work, to install the Qt framework.
Deploying the other way is explained here, read the part related to Static Linking.