How to detect if Visual C++ 2017 Redistributable is installed
Asked Answered
H

4

24

With Microsoft changing the pattern of registry entries in its latest versions, how do i detect if Visual C++ 2017 Redistributable is installed on a machine?

My aim is to install VC++2015Redist since the software is written using VS2015. If i can successfully detect VC++2017Redist on a machine, then I skip my installation of VC++2015Redist

Haymaker answered 12/9, 2017 at 14:4 Comment(8)
But... why? What is the point? If your program needs it, ship the redistributable with your program. If your program doesn't, then don't.Springing
@DietrichEpp I think OP wants the installation package to check if the redistributable is already installed, in which case that step can be skipped.Candie
@Simple: I want to hear the OP's answer.Springing
@DietrichEpp: My installation package needs to install VC++2015. However, if the machine already has VC++2017, I skip. If you try to install VC++2015 on a machine that has VC++2017, IT FAILS !Haymaker
Run redist installer with /passive flag.Pilferage
Not verified, but does this helps? zzz.buzz/notes/vc-redist-packages-and-related-registry-entriesCrouch
@Crouch : I'm unable to find those reg keys on my machines that has VC++2017. Looks like that article is outdated for the latest versionsHaymaker
Can you just (attempt to) run a trivial test exe, which itself uses the redistributable before returning 0? I assume the script or installer can get return codes from an exe call.Archibald
L
27

The 2017 VC++ Redistributable installation upgrades/REPLACES the 2015 installation

Installation of the Visual Studio 2017 Redistributables upgrades and replaces any existing installation of the 2015 Redistributables. I've checked this, and the 2015 installation disappears from "Add/Remove Programs", and the registry values (see below) have their version numbers updated. Further, per MSDN, the 2017 VC++ Redistributables have Binary Compatibility with the 2015 version.

It's possible to check whether 2015 or 2017 are installed by checking the registry keys described below. This is for a x64 system, have a look without the Wow6432Node for a 32-bit system.

Keys:

For 64-bit VC++ Redistributable

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\x64

For 32-bit VC++ Redistributable

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\x86

The properties and values are the same (same format) for both 32- and 64-bit installations. Registry Values of use:

Value          2015       2017 
Name      Val. Data  Val. Data
--------  ---------  ---------
Major            14         14
Minor             0         13
Bld           23026      26020

Note that the @Minor and build (@Bld) numbers of 2017 continue to change as new patches are updated.

I would suggest, if checking for a minimum that 2015 is installed, just checking the key and that the @Major version is 14.

If checking for 2017, with the intention of doing an upgrade if it's not in existence, then just check the @Bld number, and if it's not at least the version that can be installed, then go ahead and install the current 2017 version. Note that future updates the the @Minor and @Bld version are probable -- I've got another computer where v14.11.25325 is installed, also a 2017 version.

Lovellalovelock answered 19/4, 2018 at 18:26 Comment(4)
Note that there was a bug in a series of the VC++ 2017 redist installers that actually deleted this key when upgrading from VC++ 2015. I have not been able to find a reliable way to detect installation of VC++ 2017 installation when this occurs.Pasteboard
I used the following path to detect x86 redist "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VC\Servicing\14.0\RuntimeAdditional\Install"Skat
It doesn't work 100% of the time : imgur.com/a/xUn0czJMarras
@Eynix: you have "2015-2022" installed, thus you have "2017".Maillot
H
11

VC redistributable is now joined for VisualStudio 2015-2019. If you try to install "older" one (e.g. just 2015) if you have any newer version (e.g 2017) you get error (end of this reply).

As @CJBS wrote, it writes itself to registries, but sadly I have noticed another place of record (so check it also):

For 32-bit VC++ Redistributable

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x86

For 64-bit VC++ Redistributable

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x64

I suggest to read @Bld DWord record and compare it to determine if you need more recent version: 2015 (Bld = 23026) 2017 (Bld = 26020) 2019 (Bld = 27820)


Error message image: 0x80070666 - Another version of this product is already installed. Installation of this version cannot continue...

Holton answered 3/10, 2019 at 7:29 Comment(1)
looks like it doesn't always work : imgur.com/a/RsjjlHLMarras
L
0
# Check VCRedist current version
$OS= if ( ${env:ProgramFiles(x86)} ) {"\WOW6432Node"} else {"\"}
    $vcredist = Get-ItemProperty -Path "HKLM:\SOFTWARE$OS\Microsoft\VisualStudio\14.0\VC\Runtimes\x86" -ErrorAction SilentlyContinue -ErrorVariable eVcRedist
if ($eVcRedist) {
    $Warning += @( "Abbyy FineReader 15 requires VCRedist." )
}
elseif (($vcredist.Bld -le 24215)) {
    $Warning += @( "Abbyy FineReader 15 requires VCRedist." )
}
Lamp answered 16/12, 2020 at 3:13 Comment(0)
W
-4

You're solving the wrong problem. You're trying to install an outdated redistributable that was only suitable for VS2015 (Toolset v140). Instead, install the current VS2017 redistributable (Toolset v141). It's backwards compatible with VS2015.

Withrow answered 12/9, 2017 at 14:26 Comment(7)
That will very likely fail too, when the machine will have already installed VS2345 redistributable, so the OP will be in the same situation like now (unless he repackages his app with the latest redistributable installer at the MS release day).Malti
@Ped7g: True, but that is by design. You can't detect the registry keys of VS2345. You try to install the latest version known to you. It's up to future installers to block outdated installers.Withrow
So the answer to original question is, that "his installer fails"... but that can fail for various reasons, and failure due to more recent distributable installed is ok to ignore, as they should be backward compatible, but different failures like insufficient space are not good to ignore... so if the OP will rephrase his question, he's still in problematic situation, not capable to tell whether the failure is ok or not. (I have no answer neither, I don't work with MS technologies for 10+ years, I'm just curious, plus I felt obliged to point out your answer is leading nowhere)Malti
(as far as I'm concerned, "broken by design" is something I can easily accept with MS tech, so no surprise for me :) )Malti
@Ped7g: In general, you can just ignore such failures at install time.Withrow
Although I see your point about just installing the latest one that is backwards compatible, it doesn't address the fundamental question. It should absolutely be possible to detect what is currently installed. You don't want an installer to unconditionally install something that might already be present on the machine.Womenfolk
There are all kinds of reasons a developer wouldn't or couldn't ship a more recent redist as default without being that you don't want to use a more recent one if it's available, so that the end-user can override the distrib you use by installing an up-to date one.Taddeusz

© 2022 - 2024 — McMap. All rights reserved.