Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
[solved]Problem of deploying QT application on windows
coolz last edited by
I am now facing problem of deploying QT application on windows. I want to deploy the application by using shared libraries approach with manifest files.
I did the steps by following this doc: http://doc.qt.nokia.com/4.6/deployment-windows.html. And it worked on most of the computers that without Qt and
msvc redistribute. But one the computer failed to start the program. From the depends analysis, it says "...QtCore4.dll contains error...140001"
My environment: Qt 4.6.2 and msvc 2005 with sp1, win 7; target computer: win 7 /win xp
Install the msvc redist 2005 would fix that problem, but that's the limitation, customers may not have the privilege to install redist. I need a standalone, side by side application
following is the directory structure:
One more thing about depends tool, when I check the modules that qtcore4.dll depends, it always looks for the x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927 which is the latest vc80 dll on my computer. But the manifest file embedded in that dll specifies the crt version to: name="Microsoft.VC80.CRT" version="8.0.50727.762", and I have both versions on winsxs directory.
I also did some changes to the app.exe.manifest file by removing the publictoken element, because some article says without that, the sxs manager will try to locate the dll from current path. now the manifest looks like:
@<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86"></assemblyIdentity>
Did anyone encounter this before? Any clue would be appreciated!
goetz last edited by
I don't have a solution for the redist problem. We require it to be installed on every client machine (in fact we put the exe into our installer and run it from there). It might be possible to put the DLLs besides the exe (or in a directory besides the exe), Microsoft at least states so in its docs, but it never worked out reliably for us. They wanted to solve the DLL hell and created the manifest fiasco...
Regarding the depends tool: The manifest contains the minimum version of the DLLs. The system loads the most recent version that matches the patch number. In your case this means: The most recent version 8.0.50727.xxx with xxx >= 762. Along the time you will end up with a whole bunch of SxS directories, as many applications bring their own redistributables with them.
dialingo last edited by
Once I got stuck there too. My solution was to ditch Visual Studio and use Qt Creator with MinGW. Deployment works like a charm now. With MinGw you do not force the recipients of your software to upgrade the system.
coolz last edited by
Thanks for reply, Volker and dialingo.
After hours fighting against that problem, here comes up with a solution. I turned off the "embedded manifest" option recompiled the Qt dlls from MSVC. I guess putting this line: CONFIG-=embed_manifest_dll in the .pro file will work as well. Now each Qt dll has its manifest outside, file structure becomes:
From the depends view, when Qt dll looks for MSVC dll, the dlls in current directory will be considered firstly. And the application could be launched from that machine without Qt or vcredist installed.