22

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

CJBS
  • 15,147
  • 6
  • 86
  • 135
Manjunath
  • 491
  • 2
  • 6
  • 17
  • 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. – Dietrich Epp Sep 12 '17 at 14:08
  • 6
    @DietrichEpp I think OP wants the installation package to check if the redistributable is already installed, in which case that step can be skipped. – Simple Sep 12 '17 at 14:11
  • @Simple: I want to hear the OP's answer. – Dietrich Epp Sep 12 '17 at 14:14
  • @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 ! – Manjunath Sep 12 '17 at 14:14
  • 2
    Run redist installer with `/passive` flag. – arrowd Sep 12 '17 at 14:16
  • 2
    Not verified, but does this helps? https://zzz.buzz/notes/vc-redist-packages-and-related-registry-entries/ – roalz Sep 12 '17 at 14:18
  • @roalz : I'm unable to find those reg keys on my machines that has VC++2017. Looks like that article is outdated for the latest versions – Manjunath Sep 12 '17 at 14:25
  • 3
    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. – Kenny Ostrom Sep 12 '17 at 15:13

4 Answers4

25

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.

CJBS
  • 15,147
  • 6
  • 86
  • 135
  • 6
    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. – 17 of 26 Nov 19 '18 at 20:15
  • 1
    I used the following path to detect x86 redist "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VC\Servicing\14.0\RuntimeAdditional\Install" – sluge Jun 03 '20 at 05:51
  • It doesn't work 100% of the time : https://imgur.com/a/xUn0czJ – Eynix Aug 08 '22 at 09:41
9

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...

Mailos
  • 91
  • 1
  • 2
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." )
}
Игорь
  • 1
  • 1
-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.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • 2
    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). – Ped7g Sep 12 '17 at 14:35
  • @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. – MSalters Sep 12 '17 at 14:41
  • 1
    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) – Ped7g Sep 12 '17 at 14:47
  • 1
    (as far as I'm concerned, "broken by design" is something I can easily accept with MS tech, so no surprise for me :) ) – Ped7g Sep 12 '17 at 14:48
  • 1
    @Ped7g: In general, you can just ignore such failures at install time. – MSalters Sep 12 '17 at 14:51
  • 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. – shawn1874 Mar 16 '18 at 19:10
  • 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. – kfsone Jul 28 '18 at 23:52