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


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 (33)

  1. Question: You previously posted a list of command line switches to perform silent and unattended installations

  2. Sangeeta says:

    I tried the following command line to install silently:

    Vcredist_x86.exe /q

    But it does not supress UI. :(

    Can you post command lines used to install silently the Visual Studio 2008 SP1 release of the VC 9.0 redistributable packages?

  3. astebner says:

    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?

  4. Sangeeta says:

    Hi Astenber -Thanks for the quick response. Let me quickly explain you the scenario.

    I am launching VC++ 2008 SP1 executable through an application and not through command line.

    For the previous version of the vcredist i.e. 2005 SP,I used to pass following command line and it used to work fine.

    szSwitches=L"/q:a /c:"VCREDI~3.EXE /q:a /c:""msiexec /i vcredist.msi /qn"" "";

    The above command line is mentioned by you in one of the blog :) and it is meant for the extracted executable and not for the vcredist_x86.exe bootstrapper.

    Do you know the similar command line for VC++ 2008 SP1 that we pass to msiexec for the extracted executable?

  5. astebner says:

    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.

  6. Sangeeta says:

    Thanks Aaron!I will try using /q.

  7. kmat says:

    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}

  8. astebner says:

    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.

  9. JJInnSoft says:

    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)?

  10. astebner says:

    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.

  11. JJInnSoft says:

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

  12. astebner says:

    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.

  13. James says:

    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.

  14. astebner says:

    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

  15. Jürgen says:

    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.

  16. astebner says:

    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.

  17. mdb-blog says:

    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

  18. Varun Chadha says:

    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?

  19. Varun Chadha says:

    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.

  20. astebner says:

    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.

  21. Varun says:

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

  22. astebner says:

    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.

  23. dg says:

    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.

  24. dg says:

    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.

  25. astebner says:

    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.

  26. bcoleman@peachtree.com says:

    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.

  27. astebner says:

    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.

  28. bcoleman@peachtree.com says:

    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: http://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.

  29. astebner says:

    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.

  30. Brian says:

    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,

  31. astebner says:

    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.

  32. Brian says:

    Thanks Aaron, very much appreciated.

  33. Brian says:

    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