Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
I saw a couple of previous blog posts that you wrote about how to detect the presence of the Visual C++ 2005 runtime files and the Visual C++ 2005 SP1 runtime files. I am creating an installer that requires the Visual C++ 2008 runtime files. How can I detect the presence of the Visual C++ 2008 and 2008 SP1 runtime files?
Like in the Visual C++ 2005 runtime files, there is not a specific detection mechanism designed and built into the Visual C++ 2008 runtime files installers. You can use an algorithm like the one I described in my previous blog posts to detect the presence of the Visual C++ 2008 runtime files products on a system:
Visual C++ 2008 runtime files
Visual C++ 2008 SP1 runtime files
Visual C++ 2008 SP1 ATL Security Update runtime files
Visual C++ 2008 SP1 MFC Security Update runtime files
<update date="11/19/2009"> Added information about the Visual C++ 2008 SP1 ATL Security Update product codes. </update>
<update date="11/7/2011"> Added information about the Visual C++ 2008 SP1 MFC Security Update product codes. </update>
Hi Jurgen - I'm surprised to hear that there are different product codes in the different language versions. In that case, when writing an installer, you'll need to check the installed state of all of the product codes, or you can just skip detecting whether or not the VC++ redistributable is installed and always install it as a part of your setup just in case.
If you only check for the English product code, it also wouldn't be that big of a deal if the Spanish version was present and you went ahead and installed the English version anyways. It will take a little extra time during your installation, but it shouldn't harm the user's system at all.
Here is a full example of detecting Visual C++ 2008 SP1 run-time files (Visual C++ 9.0 run-time redistributable package)
Nice writeup. Suppose instead of using MsiQueryProductState API, I try to find the relevant registry key under HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<relevant productCode>. If it exist I'am done. Is this the correct method?
Am afraid it is, because i cannot find any such ProductCodes(for vcredist_x86/vcredist_x86_sp1) at above location. Infact these productCodes are not present anywhere in registry. Am i going wrong somewhere?
I would add that this was analysed with redistributable not installed explicitly. I have VS 2008 installed on my machine. However, registry key do exist when vcredist_x86_sp1 is installed explicitly.
Hi Varun Chadha - Yes, it should be safe to use the registry value under the Uninstall key to check for the existence of the redistributable. Visual Studio 2008 installs a subset of the Visual C++ runtime files, but it does not install the full redistributable package. That could be why you're not seeing that Uninstall registry value on your computer.
What do we mean by subset of C++ runtime files? Is there a need to install runtimes on machines already having VS?
Hi Varun - The VS setup program only installs the C++ runtime files that it needs. If your application only depends on the same C++ runtime files that VS itself uses, then your installer could check for the presence of VS instead. Overall though, I think it is easier to just use the VC++ redistributable installer in your application's installer.
in the post on 2005 redists, it is mentioned they are a "major upgrade" and when you install the SP1 or SP1 with ATL they remove the previous versions.
but with 2008, there does not appear to be the "major upgrade" functionality and the SP1 and SP1 with ATL installers leave the previous versions on the system.
what is the best way to handle providing support in a "standard" image? should only the latest 2005 be installed, and all the 2008 versions?
is there a reason the "major upgrade" functionality was changed.
to add: it appears that 2010 has reverted to the previous functionality of 2005 and it will remove previous versions upon install of 2010 SP1. the difference though is that you cannot install a previous version again.
with 2005 you could install the older version and it would change the registry, changes i imagine are not for the better.
Hi DG - Unfortunately, there have been behavior changes in the installers for some of the service packs of the Visual C++ Redistributable. I don't know why the behavior has been changed, and I don't know of a way to predict whether or not they will change again in the future. I'd suggest building your installer based on the behaviors of the currently shipping versions of the VC++ Redistributable and then keeping an eye out for future releases in case the installer behavior changes again.
I'd also strongly suggest posting a bug on the Connect site at connect.microsoft.com/visualstudio to let the Visual C++ team know about the pain that this type of setup behavior change can cause for application installers. I've told them myself, but it helps to have other people reinforce this type of message too.
I'm very sorry for the hassles that these behavior changes have caused.
This technique does not appear to work for VS 2008 SP1 run-times installed by merge modules. You must install the runtimes using the vcredist_xxx.exe in order for them to be detected by this technique.
The runtimes could exist in the side-by-side folder, yet this technique will indicate they are not present.
Hi GWC - You're right. The information in this blog post is specific to the redistributable installer for the VC++ runtime files. The merge modules don't provide a reliable detection method, but when you merge them into your MSI, the install process for your MSI will end up using standard Windows Installer reference counting logic for the components that install the VC++ runtime files.
You might want to update this entry to cover the Guids for the latest version of the run-time, the so called MFC Security Update: www.microsoft.com/.../details.aspx
The problem we encountered was that our product was installing a third-party product A, which internally installed a third-party product B. Product B implemented the logic above, and when it could not find a version of the SP1 runtime, it would put up a dialog box with a link to the Microsoft re-distributable.
Two issues with this. First, our product installed the SP1 run-time with a merge module, so there's no reason for the dialog. Second, our users would not read the dialog or click the link, and instead can't get their software to work and they call us on the phone.
A third, minor issue was that the product B installer is using a link to a very old version of the run-time (9.0.30729.1) which has a number of security flaws.
Based on this, I don't believe this technique is a very reliable indicator if the VC 2008 SP1 run-time is installed, since it doesn't detect run-times installed via merge modules, nor does it detect later updates of the run-time.
Hi G W C - I've added information about the MFC security update to the blog post. Thank you for the suggestion.
You're right that this technique isn't very reliable. I've said this in some of my other blog posts and comments - there isn't a 100% reliable way of detecting the install state of the VC++ Redistributable package. The detection logic will work in some cases, but in some others it will report that the redistributable is not installed when the payload is actually installed. That is why I normally suggest that an application always install the redistributable as a part of their setup if they need it, and don't try to detect whether or not it is installed.
Unfortunately, that type of recommendation doesn't help for an installer like the one you describe where instead of installing the redistributable, it instead just provides a download link. There will inevitably be cases where it offers the download link to customers who don't technically need to download the redistributable.
I wondered whether you knew what the definitive criterion is for detecting the installation of Visual C++ Redistributable for Visual Studio 2012 Update >= 1 on different Windows platforms please?
The only reference I can find to this problem is:
stackoverflow.com/.../detect-if-visual-c-redistributable-for-visual-studio-2012-is-installed on stackoverflow, but it doesn't provide an unambiguous answer.
I need to detect the installation of the x86 package and, on x64 operating systems, the installation of the x64 package as well the x86 package.
I've found that on:
Windows XP (x86):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\11.0\VC\Runtimes\x86 is created when the x86 package is installed and is removed when the x86 package is removed.
Windows 2008 and Windows 7 Home Premium:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\11.0\VC\Runtimes\x86 is created when the x86 package is installed and is removed when the x86 package is removed.
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\11.0\VC\Runtimes\x64 is created when the x64 package is installed and is removed when the x64 package is removed.
However, on my Window 7 Enterprise machine:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\11.0\VC\Runtimes key isn't created when either x86 or the x64 package is installed. (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\11.0\VC\Runtimes doesn't exist either).
So I'm stumped as to why Window 7 Enterprise doesn't appear to be consistent with Windows XP (x86), Windows 2008 and Windows 7 Premium and also what the criteria is for this operating system.
Thanks very much in advance,