Partager via

Mailbag: How to detect the presence of the Visual C++ 9.0 runtime redistributable package

  • Article

Question:

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?

Answer:

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:

  1. Call the MsiQueryProductState API
  2. Pass in the product code for the package that you want to detect based on the list below
  3. Check the return value of this API.  If it is anything other than INSTALLSTATE_DEFAULT, the package is not yet installed

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>

Comments

  • Anonymous
    March 26, 2009
    The comment has been removed

  • Anonymous
    April 02, 2009
    The comment has been removed

  • Anonymous
    April 02, 2009
    Hi Sangeeta - I'm sorry, but I'm not able to reproduce what you describe.  I downloaded the VC++ 2008 SP1 redistributable from http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2, then ran vcredist_x86.exe /q and it installed successfully with no UI displayed. What exact UI screens do you see in this scenario?  Do you have any logs named %temp%dd_vcredist*.txt that might help explain why it is not running in silent mode on your system?

  • Anonymous
    April 16, 2009
    The comment has been removed

  • Anonymous
    April 17, 2009
    Hi Sangeeta - I posted silent install instructions for the VC++ 2008 and VC++ 2008 SP1 runtime redistributable packages at http://blogs.msdn.com/astebner/archive/2009/03/26/9513328.aspx.  You only need to use /q and you don't need to run msiexec like you did in the VC++ 2005 redistributable.

  • Anonymous
    April 21, 2009
    Thanks Aaron!I will try using /q.

  • Anonymous
    November 17, 2009
    For who might be interested, these are the product codes for VS2008 SP1 with ATL security updates (9.0.30729.4148): x86: {1F1C2DFC-2D24-3E06-BCB8-725134ADF989} x64: {4B6C7001-C7D6-3710-913E-5BC23FCE91E6} ia64: {977AD349-C2A8-39DD-9273-285C08987C7B}

  • Anonymous
    November 19, 2009
    Hi Kmat - Thank you for adding this information.  I will update the main blog post soon as well to hopefully make these product codes easier for folks to search for and find in the future.

  • Anonymous
    December 16, 2009
    I see a number of comments suggesting to use a series of product codes to detect the VC2008 runtime.  But Microsoft is always coming out with new versions (service packs and security updates).  Suppose I check for all these GUIDs in my installer, but then Microsoft comes out with a new update and an end-user has previously installed only that new version.  My older installer would fail to recognize this new version and try to install an older version of VC2008 runtime which probably has security holes.  What's the best way of dealing with this scenario?  Is it better to somehow detect newer, as-of-yet unreleased versions of the runtime (perhaps using the upgrade code of the MSI) and not install anything?  Or is it better to force installation of the older version of the runtime (which would happen with the currently-described detection algorithm)?

  • Anonymous
    December 18, 2009
    Hi JJInnSoft - Most of the cases I've seen in the past where an installer includes the VC++ redistributable, the application requires that exact version of the VC++ runtime files.  In those cases, it is best to install that version, even if other versions are already on the system.  There are other options for managing the VC++ runtime file dependency in your application as well (statically linking, deploying the DLLs application-local, etc).  These options all have pros and cons, so you have to evaluate them and decide what makes the most sense for your scenario.  I wrote about some of the options and include links with additional information for you to look at to help make this decision in the blog post at http://blogs.msdn.com/astebner/archive/2007/01/09/problems-with-custom-actions-that-depend-on-the-visual-c-8-0-runtime-files-on-windows-vista.aspx.  There are also some helpful posts on this topic on Nikola Dudar's blog at http://blogs.msdn.com/nikolad/archive/tags/VC_2B002B00_+Libraries+Deployment/default.aspx.

  • Anonymous
    December 22, 2009
    I did some further investigation by opening the various runtime available runtime downloads in Orca and found the following:

  • Upgrade code for C++ 2008 redistributable for RTM, SP1, and ATL security update are all {AA783A14-A7A3-3D33-95F0-9A351D530011}.  They have unique product codes as noted in the original blog post.

  • Upgrade code for C++ 2005 redistributable for RTM and ATL security update versions are both {86C9D5AA-F00C-4921-B3F2-C60AF92E2844}.  I did not check the other versions (e.g. SP1) but I assume they have the same upgrade code too.  They also have unique product codes as noted in a different blog post. Is it same to assume that these upgrade codes are unique for the major versions of the runtime?  (I.e. future service packs and patches to VC2008 would have the same upgrade code I found, but the Visual C++ 2010 version will have a new upgrade code). This seems like the more appropriate method in my scenario, because my application should work with any installed version of the 2008 runtime (so says my manifest) and it's trivial to implement the check in WiX with the Upgrade and Condition elements (the bootloader would use MsiEnumRelatedProducts to implement the same check and run vcredist if none found).

  • Anonymous
    December 28, 2009
    Hi JJInnSoft - I believe it is safe to assume that the UpgradeCode will be the same for any service pack or security release within the same family of the VC++ redistributable (all of the 2005 versions will be the same, all of the 2008 versions will be the same, all of the 2010 versions will be the same).  Unfortunately, I don't see that officially documented anywhere, so there is some slight risk that it could change for some reason in a future servicing release. Overall, I think it is fine for you to use Upgrade + Condition checks in your installer like you describe above, but you should also plan to do some type of regression test pass in the future if/when new service packs or security fixes are released for the version of the VC++ redistributable that your product depends on.

  • Anonymous
    September 03, 2010
    I realize no one has posted on this in a while but I'm curious is there is a /norestart switch for the C++ 2008 redist? Does /norestart work or is there some other switch that needs to be used.

  • Anonymous
    September 03, 2010
    Hi James - It doesn't look like the /norestart switch is supported for the VC++ 2008 redistributable.  Instead, you would need to use a 2 step approach:

  1.  Extract the package by running vcredist_x86.exe /x:c:vc2008redist /q Note - you can change the path c:vc2008redist to whatever folder you want
  2.  Run the MSI directly by runnning msiexec /i c:vs2008redistvc_red.msi /q REBOOT=ReallySuppress

  • Anonymous
    October 07, 2010
    To double check the product codes I installed the Visual C++ runtimes downloaded from Microsoft, one at a time in English and German. I found out that the product codes differ for localized versions of the redistributables for VC++ 2008.

  • Visual C++ 2008 Redistributable Package (x86):  German: {09298F26-A95C-31E2-9D95-2C60F586F075}  English: {FF66E9F6-83E7-3A3E-AF14-8DE9A809A6A4}

  • Visual C++ 2008 SP1 Redistributable Package (x86):  German: {6AFCA4E1-9B78-3640-8F72-A7BF33448200}  English: {9A25302D-30C0-39D9-BD6F-21E6EC160475} (I did not check X64 so far) For VC++ 2005 and VC++ 2010 the product codes seem to be the same for all languages, according to my evaluation, but I am not sure because I just checked German and English. This is a massive problem when detecting an installed Visual C++ 2008 runtime in an application that runs on non English systems. In case the application checks for the product code of the English runtimes, but a Spanish runtime is installed for example, the check would fail.

  • Anonymous
    October 08, 2010
    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.

  • Anonymous
    November 23, 2010
    Here is a full example of detecting Visual C++ 2008 SP1 run-time files  (Visual C++ 9.0 run-time redistributable package) mdb-blog.blogspot.com/.../bootstrapper-package-detect-vcredist.html

  • Anonymous
    January 31, 2011
    Hi Aaron, Nice writeup. Suppose instead of using MsiQueryProductState API, I try to find the relevant registry key under HKLMSoftwareMicrosoftWindowsCurrentVersionUninstall<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?

  • Anonymous
    January 31, 2011
    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.

  • Anonymous
    January 31, 2011
    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.

  • Anonymous
    February 01, 2011
    What do we mean by subset of C++ runtime files? Is there a need to install runtimes on machines already having VS?

  • Anonymous
    February 02, 2011
    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.

  • Anonymous
    July 25, 2011
    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. blogs.msdn.com/.../updated-vc-8-0-runtime-redistributable-packages-are-included-in-visual-studio-2005-sp1.aspx 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.

  • Anonymous
    July 25, 2011
    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.

  • Anonymous
    August 02, 2011
    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.

  • Anonymous
    November 05, 2011
    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.

  • Anonymous
    November 05, 2011
    The comment has been removed

  • Anonymous
    November 07, 2011
    The comment has been removed

  • Anonymous
    November 07, 2011
    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.

  • Anonymous
    July 18, 2013
    Hi Aaron, 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_MACHINESOFTWAREMicrosoftVisualStudio11.0VCRuntimesx86 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_MACHINESOFTWAREWow6432NodeMicrosoftVisualStudio11.0VCRuntimesx86 is created when the x86 package is installed and is removed when the x86 package is removed. HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftVisualStudio11.0VCRuntimesx64 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_MACHINESOFTWAREWow6432NodeMicrosoftVisualStudio11.0VCRuntimes key isn't created when either x86 or the x64 package is installed. (HKEY_LOCAL_MACHINESOFTWAREMicrosoftVisualStudio11.0VCRuntimes 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,

  • Anonymous
    July 21, 2013
    Hi Brian - I've talked to the team that created the installers for the VC++ redistributable packages about this type of scenario in the past, and there is not a definitive way to detect the presence of these redistributable packages.  Their recommendation is to always attempt to install it as a part of an application's setup program if it needs to be sure that the VC runtimes are present on the computer.

  • Anonymous
    July 21, 2013
    Thanks Aaron, very much appreciated.

  • Anonymous
    July 21, 2013
    Hi Aaron, To cover the Windows 7 Premium case I've enumerated all the installed programs (using C#) and then looked for the string 'Microsoft Visual C++ 2012 Redistributable (x64)' and 'Microsoft Visual C++ 2012 Redistributable (x86)' as appropriate. It isn't particularly elegant but it does seem to work. Thanks again, Brian