PDA

View Full Version : VC 2013 redistributable redundant install



musabio
06-29-2017, 03:41 PM
I've noticed that the VC 2013 x86 Redistributable installs itself every time, even if it has already been installed, and even if there is a more recent version already installed.

(The current version available from Microsoft is 12.0.40649 while the SetupBuilder version is still 12.0.12005)

It wouldn't be such a problem if the package wasn't so big that it may take several seconds to download/install, while displaying the associated"Extracting temporary Microsoft Visual C++ ... runtime files" and installation dialogs. Which has resulted from some complaints from our users in that our updates are more UI-intrusive than they would otherwise be.

Is this behavior normal? Perhaps it is out of your hands, but if so, can you suggest an optimum approach to script around it? (It would be very helpful if such logic was built in to the redistributable script!)

Thanks,
Musabio

linder
07-03-2017, 03:16 AM
Musabio,

We'll check this and I get back to you.

Thanks,
Friedrich

linder
07-03-2017, 04:14 AM
Update: MS changed the VC++2013 redist deployment method a bit (to bring it in-sync with the VC+2017 module). We'll make a new Core PreRequisite for 12.0.40660 available soon. I'll post here when available.

Thanks for the report!

Friedrich

linder
07-03-2017, 06:03 AM
Musabio,

The new VC++ 2013 Version 12.0.40660 Core PreRequisites for SetupBuilder 10 are available now. Does this work for you?

Thanks,
Friedrich

musabio
07-03-2017, 09:32 AM
Thanks for the update - at least now my install package is back in sync with the latest from Microsoft.
The problem of avoiding the redundant extraction remains, but I guess it's not that difficult to just script around it using something like:


! Install VC++ redist x86 12.0.40660 if not already installed...
Set Variable %VC_REDIST_VER% to FUNCTION:Get Registry Key Value ("Version") from "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Insaller\Depen dencies\{61087a79-ac85-455c-934d-1fa22cc64f36}
If %_SB_ERRORCODE% Equals "0" Then
#include script "rt_vc2013redist_x85.sbi" [Config] ==> [_RT_VC2013X86_ASK_USER]=0
End

In a perfect world the registry key (which changes with every update) and its associated test would be bound to the sbi include script so that we don't have to hunt it down and update the Set Variable statement each time there is an update of the redistributable. But it only really matters for "web" installs (where the module currently has to be separately downloaded before it see if it is is already installed). And it's not that big of a deal now that I understand it.

Thanks,
Musabio

linder
07-04-2017, 03:32 AM
Hi Musabio,

Yes, the above key is not a good candidate to handle it (as you already mentioned, it changes). The only way to handle "in-place" upgrades (introduced in VC++2017 and "backported" to some newer redistributables) is to use the "Upgrade GUID" (using the "Get Related Product" script logic in the updated .sbi).

Friedrich

musabio
07-04-2017, 10:46 AM
I may have misunderstood the logic in the updated .sbi, or at least the way the \uninstall\ keys in the registry work. The script in this case is looking for
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\Uninstall\{E30D8B21-D82D-3211-82CC-0F0A5D1495E8} (or the WOW6432nODE equivalent), whose presence is correctly causing it to skip over the reinstall. (The "Get Related Product" function on {B59F5BF1-67C8-3802-8E59-2CE551A39FC5} returns the same key.) But when I try to test this by uninstalling the C++ 2013 Redistributable (x86) package, although the package is removed from the list of installed programs as seen in the Control Panel, that key remains in the registry, and thus the sbi script from that point forward acts as if it is still installed (i.e. skips the reinstall) even though it isn't installed.

Furthermore, if I rename that key, the sbi script will then install the package each time I run it (which was the original complaint.) The package shows up in the Control Panel list of programs, and otherwise acts as it it's installed, but the key in question is not recreated in the registry, thus causing sbi script to redundantly reinstall it each time.

It's possible that I've muddied the situation trying to test it under different scenarios by manually installing and uninstalling it multiple times. And it may be that part of the problem is that the Windows uninstaller is failing to remove the \uninstall\ key, and/or that there is some kind of mismatch between the key that the redist installer is using and the one the sbi is checking. Certainly Microsoft deserves our awe for making it complex almost beyond the limits of mortal comprehension;)

But I guess what you're saying is that theoretically the sbi logic should handle this, particularly with the newer redistributables. But it wouldn't hurt for me to add my own test to avoid the redundant reinstall problem for this particular C++ redistributable. (The fact that the key may change is a problem for maintaining the application install script, but it wouldn't change unless I used the Redistributable Manager to download a new version of the redistributable package.)