This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Visual C++ 2015 runtime
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 26, 2016
03:38 PM
Handling Detection of Visual C++ 2015 x86 Runtime Without Checking Product
Hi all,
I'm trying to find a better way to detect the presence of our minimum VC++ 2015 requirement without checking version specific registry information specific to its version. Currently, the requirement is checked for installation by checking a version under its Product Code registry key. The problem is that if a newer version, with a different product code is in place, my prerequisite installer will fire and fail as Microsoft doesn't allow that I guess.
Checking for the x64 version is nice because it just deals with the actual version of the runtime installed and not specific to that versions install package.
HKLM\Software\Microsoft\DevDiv\Servicing\14.0.
I did find another code that would be nice to use as it is also not tied to a product code registry key...
HKLM\Software\Microsoft\VisualStudio\14.0\VC\Runtimes... This key has x86 and/or x64 keys sub-keys, which hold versioning information. The only issue here is that the version information is not held in a single value...
Major = 14
Minor = 0
Bld = 23918
Rbld = 0.
So I don't have a way using the prereq editor to use compound conditions.
Is there any way I can better handle the installation of VC++ runtimes (x86) so that I don't run up against conflicts attempting to install our minimum over a more recent version.
I know this might be confusing so fire any questions if you think you can help. I guess I could ask if there is a way to handle compound conditions in prereq editor.
For now, we're living with this as the search criteria...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{2e085fd2-a3e4-4b39-8e10-6b8d35f55244}
BundleVersion = 14.0.23918.0
Using the version comparison works fine, but again its tied to that product code.
Maybe a better approach would be to check a file version instead of dealing with installation package information. The files are probably installed to standard locations so that might be an easier thing to check. ??
Any pointers appreciated!!
I'm trying to find a better way to detect the presence of our minimum VC++ 2015 requirement without checking version specific registry information specific to its version. Currently, the requirement is checked for installation by checking a version under its Product Code registry key. The problem is that if a newer version, with a different product code is in place, my prerequisite installer will fire and fail as Microsoft doesn't allow that I guess.
Checking for the x64 version is nice because it just deals with the actual version of the runtime installed and not specific to that versions install package.
HKLM\Software\Microsoft\DevDiv\Servicing\14.0.
I did find another code that would be nice to use as it is also not tied to a product code registry key...
HKLM\Software\Microsoft\VisualStudio\14.0\VC\Runtimes... This key has x86 and/or x64 keys sub-keys, which hold versioning information. The only issue here is that the version information is not held in a single value...
Major = 14
Minor = 0
Bld = 23918
Rbld = 0.
So I don't have a way using the prereq editor to use compound conditions.
Is there any way I can better handle the installation of VC++ runtimes (x86) so that I don't run up against conflicts attempting to install our minimum over a more recent version.
I know this might be confusing so fire any questions if you think you can help. I guess I could ask if there is a way to handle compound conditions in prereq editor.
For now, we're living with this as the search criteria...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{2e085fd2-a3e4-4b39-8e10-6b8d35f55244}
BundleVersion = 14.0.23918.0
Using the version comparison works fine, but again its tied to that product code.
Maybe a better approach would be to check a file version instead of dealing with installation package information. The files are probably installed to standard locations so that might be an easier thing to check. ??
Any pointers appreciated!!
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 28, 2016
09:52 AM
Hello Superfreak,
I would recommend you to make this comment in the following forum too:
https://blogs.msdn.microsoft.com/vcblog/2016/04/18/c-runtime-deployment-why-choosing-applocal/
Please see the comment by user BAR36.
We have the same problem.
Regards
André
I would recommend you to make this comment in the following forum too:
https://blogs.msdn.microsoft.com/vcblog/2016/04/18/c-runtime-deployment-why-choosing-applocal/
Please see the comment by user BAR36.
We have the same problem.
Regards
André
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 26, 2018
10:33 AM
I have a similar issue. The machine in question has Visual C++ 2015 update 3 x64 already installed by another application. Then my install comes along and checks the registry setting you mentioned. Low and behold it finds it in
HKLM\Software\Microsoft\DevDiv\Servicing\14.0. The only problem is that my application is 32-bit running on 64 and I need the 32-bit version of the run-time. So that registry location does not work - I think you were saying the same thing.
So I tried looking up the GUID in the uninstall strings. Unfortunately, another machine that I tested this on had a newer version of the runtime -- but since the registry information was missing, it tried to install it even though it was not needed. This lead to a message that a newer version was already installed. Yes, it is only time lost but seriously there should be a cleaner way to check for this run-time.
HKLM\Software\Microsoft\DevDiv\Servicing\14.0. The only problem is that my application is 32-bit running on 64 and I need the 32-bit version of the run-time. So that registry location does not work - I think you were saying the same thing.
So I tried looking up the GUID in the uninstall strings. Unfortunately, another machine that I tested this on had a newer version of the runtime -- but since the registry information was missing, it tried to install it even though it was not needed. This lead to a message that a newer version was already installed. Yes, it is only time lost but seriously there should be a cleaner way to check for this run-time.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 26, 2018
03:18 PM
MattQVI wrote:
I have a similar issue. The machine in question has Visual C++ 2015 update 3 x64 already installed by another application. Then my install comes along and checks the registry setting you mentioned. Low and behold it finds it in
HKLM\Software\Microsoft\DevDiv\Servicing\14.0. The only problem is that my application is 32-bit running on 64 and I need the 32-bit version of the run-time. So that registry location does not work - I think you were saying the same thing.
So I tried looking up the GUID in the uninstall strings. Unfortunately, another machine that I tested this on had a newer version of the runtime -- but since the registry information was missing, it tried to install it even though it was not needed. This lead to a message that a newer version was already installed. Yes, it is only time lost but seriously there should be a cleaner way to check for this run-time.
Yeah, that's a sticky situation. The x64 package writes the registry keys for both architectures. I'm not sure why. Maybe if installing x64 installed both that and x86, but that's not the case. Maybe this will help...
https://zzz.buzz/notes/vc-redist-packages-and-related-registry-entries/#x86-140242151
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 12, 2018
02:47 PM
Thanks Superfreak3. I will try those registry strings.
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)