0

Today I build my application and packaged the installer with QtIF. It worked nice on my computer but complained about missing msvcp140_1.dll in another computer.

Then I run find . -iname "msvcp140_1.dll" and found more than five different ones on my computer, I checked the md5sum.

Then I spend the time to try all of them on the other computer and all seem to work fine. No more complains about missing DLL.

How should I choose between the DLLs? Just pick any seems too easy.

Is there someway to inspect the DLLs, to check for a version?

I believe that DLL was a dependency from another binary included in my application, was not that the QtIF failed to include it.

KcFnMi
  • 5,516
  • 10
  • 62
  • 136
  • Usually Microsoft DLLs ending with `d` are debug DLLs and cannot be distributed. You should be building a release version and if necessary including the MS redistributable package in your installer. – Richard Critten Jan 06 '22 at 12:17
  • It's being done in release mode. Well, at least my build, perhaps the binary which depends on `msvcp140_1.dll` isn't. And "including the MS redistributable package in your installer" sounds strange, in this case I have to ask the user to install one extra thing and I'm packaging the installer with QtIF to simplify end user life. My plan is to just add the missing DLLs. – KcFnMi Jan 06 '22 at 12:23
  • 2
    Have a read of [Redistributing Visual C++ Files](https://learn.microsoft.com/en-us/cpp/windows/redistributing-visual-cpp-files?view=msvc-170) – Richard Critten Jan 06 '22 at 12:44
  • 1
    The redist package is the correct way to do it. There'a a reason MS includes it as part of the dev SDK. Your installer should run the redist as part of its installation prior to laying down your bits, and most installer frameworks already have configuration options to do that very thing (install redist frameworks specified as part of your manifest). – WhozCraig Jan 06 '22 at 12:45
  • @RichardCritten it seems the strategy I'm adopting is on section named `Install individual redistributable files` and is not recommended very much, although the reasons (" For servicing reasons") are not convincing me. – KcFnMi Jan 06 '22 at 13:03
  • @WhozCraig why not just copy the DDLs and ship them in the same folder of my application? – KcFnMi Jan 06 '22 at 13:08
  • 1
    See also https://stackoverflow.com/questions/36972287/installing-vc-redistributables-in-a-qt-installer-framework-qtifw-installer – MSalters Jan 06 '22 at 13:57

2 Answers2

4

Call the MS Redist Installer from your Installer. This can be done quietly, so that the end user does not notice it.

  • Find the vcredist_x64.exe file (or vcredist_x32 for 32 Bit applications), add it to your installer,
  • let it extract to the "TEMP" folder
  • and then call vcredist_x64.exe /quiet at the end of your install.

This has several advantages:

  • You will definitely copy all required files to the users computer.
  • Should new versions of the runtime library be released by Microsoft and should they already be on your users computer, your code will use the newer versions, which may include bugfixes.
  • Windows Update may also update the libraries.

That said, it is possible to copy the DLLs themselves, but you should make sure a) you choose the right ones b) they come from a trustworthy place, i.e. your VS installation folder c) reside in the same directory as the executable - otherwise you will run into trouble with manifests.

The reason you might want to include the DLLs directly is if you want to reduce the overall size of your installer.

We did this a couple of years with our products, but finally gave in and simply used the vcredist_x64.exe, even if that increased the installer binary another couple of MB in size. But in the long run that's the easiest way.

I think (not sure), msvcp140_1.dll is an additional DLL for the VS 2019 runtime. VS 2017 runtime does not need this, but the new one does.

Hajo Kirchhoff
  • 1,969
  • 8
  • 17
  • You convinced me. Could you tell me more about the kind of "trouble with manifests" I might get in? – KcFnMi Jan 10 '22 at 14:34
  • Uh, manifests. That was a long time ago. I think you had to copy the manifest files as well and the DLLs and manifest files had to be in the same location as your binaries. Which, if you distribute your binaries across subfolders, get's complicated. – Hajo Kirchhoff Jan 10 '22 at 17:45
  • I'm not sure if you have to copy manifests today anymore or if they are located inside the runtime DLLs by now. If you have to, you also must make sure that the DLL versions, manifest versions match. And do not try to mix&match different versions. Won't work. – Hajo Kirchhoff Jan 10 '22 at 17:46
2

The non-redistributable method is to ship the DLL's that come with your compiler, i.e. the compiler that built your executable. After all, the DLL will be loaded into the same process as your EXE. It's only logical that these should match.

You'll find those DLL's in \Program Files*\Microsoft Visual Studio *\VC\Redist

MSalters
  • 173,980
  • 10
  • 155
  • 350