Failure when trying to install the runtime libraries aside the QT application on the end-user's system via the vcredist_xxx.exe application
-
https://doc.qt.io/qt-5/windows-deployment.html advises to install the runtime libraries aside your application on the end-user's system via the vcredist_xxx.exe application. The following link https://www.microsoft.com/en-us/download/details.aspx?id=48145 evens shows where this application can be downloaded from the web.
The problem that I am facing is that the official MS download site provides revision 14.0.23026.0 from the "Visual C++ Redistributable for Visual Studio 2015"
However when I try to install this on my machine, but I observe this on lots of host machines from the end users of my application I get an error message telling that there is already a newer version of the redistributable installed.
If anyone has an idea?
-
@Laurent-Schall Does your app work with the newer version? If so, then no need to install the runtime libraries.
-
Hi, there are many versions of the redistributable files, mostly because there are updates to Visual Studio 2015 (Update 1, 2 and 3), so this is racing game you could say.
So to stay ahead of the pack, google for the Update 3 flavor of the Redistributable (this will give you version 14.0.24212) it's here
-
@jsulm - The app works with the newer version - so yes - unfortunately there is no "ignore if newer version already installed" flag in vcredist_x64.exe. My goal is to provide an install package from my Qt application that should work on every system (where no C++ redistributable are yet installed, where already older C++ redistributable are yet installed but also where newer C++ redistributable are yet installed)
@hskoglund - The version you are pointing 14.0.24212 is also older than the one vcredist detect on my system 14.11.25125.0
-
Yeah, that version wins over my version, because Visual Studio 2019, 2017 and 2015 all reuse the same redistributable package, but can you beat version 14.21.27702?
It can be downloaded from this page
This will currently give you pole position I think :-)
-
@hskoglund I will test if it will allow my Qt application, compiled with MS VC 2015, to start on a fresh system. If yes, I'll go for it...
-
@hskoglund I am wondering if there is a ways to bypass the version of vcredist that comes with windeployqt which I guess will not be the latest one.
-
@Laurent-Schall I've been in your situation (worrying about fresh vcredists) for a long time, before Qt I used MFC which required the same (a fresh vcredist).. I tried to follow Microsoft's advice but was anyway bitten a couple of times, I remember customers waking me up a Monday morning, telling me that my program had stopped working. A Windows update of the C++ .dlls had broken my ADO database connection :-(
So when I started with Qt I always bundled the C++ .dlls along the Qt's dlls with my app. For VS2015 I copied from C:\Windows\SysWow64 on my dev. PC the 3 dlls: msvcp140.dll, vcruntime140.dll and ucrtbase.dll.
This is against Microsoft's advice but I since starting doing that my Monday mornings have been uninterrupted.But this year I followed in the footsteps of Qt's installation program qt-unified-windows-x86-3.1.1-online. Note what you download on a fresh PC is just a Qt .exe file, there's no installation, you just doubleclick it.
Earlier it was built using 32-bit MSVC2015 and I remember seeing some users here on the forum complain that they couldn't start the installation of Qt on a freshly bought Windows 10 Home PC, because it hadn't any MSVC2015 redist installed at all.
So they switched to using the 32-bit MinGW compiler. That compiler explicitly wants you to bundle the needed .dlls with your app (contrary to Microsoft) and thus for windeployqt it is kosher to copy them (windeployqt uses the distro of MinGW that's inside C:\Qt\Tools). Or you can do like Qt's installation program and link them statically.First I was afraid of some incompability between MinGW and MSVC runtimes and I tested a lot of Win32 stuff from Qt, like hooking hotkeys and using the systray etc. But MinGW worked just fine.
So switching to MinGW could be one escape from VCRedist angst for you as well, or if you don't want to switch, copy the MSVC .dlls along with your .exe file.
-
@hskoglund Thanks for this - Yes MingGW is definitely something I could be looking in - although I have noticed that MinGW takes almost 3 times the time to compile my project compared to what is needed by the MS VC compiler (My project is quite big and already takes several minutes to fully compile with the MS VC compiler). For now I will make sure to deliver the latest version of vcredist aside the app. Here is how I modified my .pro file to exchange the vcredist coming along with windeployqt and the one I got from the link you gave me.
-
@Laurent-Schall said in Failure when trying to install the runtime libraries aside the QT application on the end-user's system via the vcredist_xxx.exe application:
app works with the newer version - so yes - u
Would this help?
Component.prototype.createOperations = function() { // Call the base createOperations and afterwards set some registry settings // so that the simulator finds its fonts and applications find the simulator component.createOperations(); //return value 3010 means it need a reboot, but in most cases it is not needed for running Qt application // return value 5100 means there's a newer version of the runtime already installed component.addElevatedOperation("Execute", "{0,3010,1638,5100}", "@TargetDir@\\vcredist\\vcredist_x64.exe", "/norestart", "/q"); }
You can add other exit codes to the list if needed.