[Qt-interest] SQLite Plugin Problem on some XP machines

[Oliver.Knoll at comit.ch]

Willy P wrote on Friday, December 05, 2008 1:43 AM:

> I'll add that Depends.exe doesn't detect anything, and that I'm using
> Qt Commercial for Studio 2005.

Okay, a complete shoot into the dark, but here we go:

We all know that since Visual Studio 2005 the concept of "side by side assemblies" and manifest files has been introduced, so depending on how you deploy the VS C++ runtime DLLs they are taken from one place or another ("You don't say!" - but I'll come to that later).

The safest way (and the way Microsoft would like you to do so, or so I understand) is to deploy the C/C++ runtime DLLs via the vcredist_x86.exe when you install your application:

  http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en

You could create an MSI-based installer with a "bootstrap" code which checks whether installing of the runtime DLLs is necessary or not, and if so, it runs the vcredist_x86.exe (respective the *.msm "merge modules" which are "merged" into your MSI setup).

You can read about MSMs and general "runtime DLL setup" here:

  http://msdn.microsoft.com/en-us/library/ms235624(VS.80).aspx

And this is where the fun already starts: as noted on the above page the Visual Studio 2005 SP1 obviously installs wrong MSM: they have a wrong "product key":

"
WARNING: VS2005 SP1 installs some MSM files with version 8.0.50727.42, but builds your code against 8.0.50727.762. WHen you deploy your app on a raw WinXP machine, it gets the 8.0.50727.42 redistributables from the MSMs, which won't work with your installed app.

My workaround is to put the 8.0.50727.762 MSM versions into "C:\Program Files\Common Files\Merge Modules"

Here are some example affected files:

Microsoft_VC80_CRT_x86.msm
Microsoft_VC80_ATL_x86.msm
"

That basically means that an incompatible runtime will be installed, or so I understand.


Another way (and I am coming back to the "one place or another") is off course to make a "private assembly", that is install the C/C++ runtime DLLs together with their manifest into the application folder (where your *.exe) is. But in case that another application already installled the C/C++ runtime in the c:\Windows\WinSxS which are possibly older (or newer) *they* are taken, instead of the DLLs you just installed into your application folder! This is by design, to make sure that your application always uses the *latest* DLLs, installed in the "proper" place c:\Windows\WinSxS folder - that's what I meant with "they are taken from one place or another" - and you can't really be sure *which* runtime DLLs are taken!

Unless... unless you hack the manifest files (both the one from the C/C++ runtimes and the one which is generated for your *.exe and all your *.dlls!), as described here:

  http://www.codeproject.com/KB/cpp/PrivateAssemblyProjects.aspx

Basically it is all about removing the "public token" from the manifest files: "The publicKeyToken attributes tell the loader in a Windows XP/2003/Vista system to look into the SxS storage for the needed DLLs. So, if we remove the publicKeyToken entries from the manifest, the program will no longer use the public installed files. It has been changed to use the requested assemblies private and application local."



So what has this all to do with your "plugin not loaded" problem? I have no clue! :) But when you say that "it runs on some machines, but it does not on others", that smells like a "DLLs not found or they refuse to link (due to manifest settings)" problem.

* Try to install the runtime DLLs with the vcredist_x86.exe (the same which matches the SP level of your Visual Studio 2005!) on a machine where the plugin refuses to load and see whether that makes a difference
* Double-check that you compile *all* your application, Qt, plugins etc. with the same SP level

And doesn't Qt - I think in DEBUG mode only - allow you to turn on some switch (an environment variable QT_DEBUG_PLUGINS) which enables verbose mode, which would maybe give a hint why the plugin was not loaded! As described here:

  http://lists.trolltech.com/qt-interest/2007-04/thread00259-0.html

Oh, and check the registry: I think Qt "caches" the results of success of loading a plugin! So once a plugin fails, it won't be loaded the next time! Unless the modified date stamp of that plugin has changed or so.

Simply try to delete the registry entries (they should be rebuilt the next time your Qt application launches) and see if that helps (also refer to the Qt interest archive link above):

  HKEY_CURRENT_USER\Software\Trolltech\OrganizationDefaults\Qt Plugin Cache 4.[x]


Cheers, Oliver