views:

1760

answers:

6

Hello,

I have a Plug-in for an application from another company. My plug-in uses Qt so it needs the Qt DLLs. My problem is that all versions of 4.x Qt Dlls are called the same, e.g. :QtCore4.dll. It is quite possible that some other plugin, or another application which inserted itself into the PATH environment variable, has put Qt dlls in the applications folder. In that case, the plug-in will not start as it is expecting a different version of the DLL.

  • Q1. What is the suggested common practice for DLL deployment ?
  • Q2. What if the host application uses a different version of Qt. Would windows allow the host application and the plug-in to use different versions () ?

Thanks!

A: 

Is there no way to choose to link statically with Qt?

I would deploy the DLLs in the same directory as my app/plugin.

This does not answer your other concerns though.

Tim
As far as I know, statically linking is only allowed for a commercial Qt license.The LGPL license requires that you allow your customers to 'relink' your application with a new version of Qt, which in practice means:Either give away the source or object files of your application.Or distribute Qt as DLL's.
Patrick
A: 

+1 on static link. See here and here.

sean e
A: 

Like Tim said you should deploy the DLL's in the same directory as the app/plugin you are making. I believe the PATH variable is not the first place your program will look for the QT4 dll so therefore if you deploy it in the same folder your app will pick up the one with your app and ignore any that are on the PATH.

Q1: In the past it seemed like everyone threw their DLLs in the system32 folder because they knew it was on the PATH and knew there program would be able to find it. From a user's point of view I find that very hard to clean up when I want to uninstall something. And now with the small price of storage I would say keep your DLLs with your app especially if they are like this where there could be multiple versions. While I'm no expert this is how I handle jar files for Java applications.

Q2: I would think so. It would depend on the directory structure of the app and plugin. You can tell your plugin which version to use and I'm willing to bet the app has its version in a special place already as well.

Patrick
A: 

With versions of Windows since XP (i.e. XP, 2003, Vista, 2008, and Win7), you can use the side-by-side assemblies or DLL redirection. In either case, essentially what you're doing is including a small text file that tells the operating system that you need to use the specific version of the DLLs you included in the same directory as the executable.

These are lesser-known features, but they can really save your butt from "DLL Hell".

ewall
The side-by-side cache makes it much harder to deploy the application in a large network.I prefer simple, zero-install, xcopy-install applications where you just have to copy the exe and some DLL's, or you even don't have to copy it but just leave it on a network drive.With the side-by-side-cache-DLL's you are forced to explicitly install the application on every PC. And if the next version requires new DLL's, then you also have to re-install the application.
Patrick
+1  A: 

A1: Best practice: put the DLL in the directory of the executable. It will look there first for loading the DLL. This is common practice.

A2: If somehow the application uses a different version of Qt and the module you are describint requires a later or specific version, it might cause a problem (not work, crash, etc).

With static Linking you would also have to consider license restrictions of Qt. LGPL is happy as long as the library is dynamically loaded at runtime and can be separated from the application. This only applies if you do not release your source, etc.

Also, your installer should set up access to those files so that they are protected from being overwritten by some other rogue application.

Klathzazt
A: 

Just to help others with this problem: QT DLL's are guaranteed to be the same (or at least binary compatible) for all 4.X Versions. (same for all 3.X Versions and so on) so there will be no Problem. This is also the reason wy there is no second number in the Qt dll naming.

nobody
However, if the configuration for two different Qt builds are different, they are not binary compatible.
swongu
And what about the 32-bit and 64-bit version of the QT DLL?Then they aren't binary compatible either.
Patrick