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 am building an installer that will include the Visual C++ (VC) 8.0 runtime files redistributable package (vcredist_x86.exe, vcredist_x64.exe and/or vcredist_ia64.exe) as a prerequisite. How can I detect whether or not this package is already installed on the user's system so that my installer can skip installing it when appropriate?
There was not a specific detection mechanism designed and built into VC 8.0 runtime files redistributable setup packages. The setup bootstrapper that ships with Visual Studio 2005 uses the following algorithm to check for the existence of these packages:
Visual C++ 2005 runtime files
Visual C++ 2005 SP1 runtime files
Visual C++ 2005 SP1 ATL Security Update runtime files
However, this algorithm is somewhat incomplete. It does not cover cases where a user has installed some other application on the system that includes the VC 8.0 runtime redistributable merge modules (MSMs) as part of its MSI package. It also does not cover the case of Windows Vista, where the VC 8.0 runtime files are installed as part of the OS. (Note - versions of Windows newer than Windows Vista do not treat the VC++ runtime files as system files anymore. See this knowledge base article for more information.)
The safest way for a setup to manage detection for the VC 8.0 runtime redistributable package is to use an algorithm similar to the one listed above to check for the MSI product code and then install if it is not yet installed. This may lead to a few cases where the setup will install it when it doesn't technically need to, but that is better than any scenarios where it could might end up not installing it when the VC runtime files are not yet present. In addition, using this approach will add a reference count to the VC runtime files to prevent scenarios where uninstalling some other application that includes the VC runtime MSMs causes the VC runtime files to be removed from the system.
One important note - the VC runtime redistributable packages require that the system has at least Windows Installer 3.0 (and ideally Windows Installer 3.1 because any future hotfixes produced for this package will require Windows Installer 3.1). If your setup is going to install the VC runtime redist package, it should also check for the presence of Windows Installer 3.x and install it as well if it is not yet installed on the system.
Other options for installing the VC 8.0 runtime files
I also want to point out that there are other options for applications that depend on the VC 8.0 runtime files besides redistributing the vcredist_x86 or vcredist_x64 MSI packages.
These options have various pros and cons, and the choice you make depends on your applications and the scenarios you want to support. There is additional discussions of some of the trade-offs on the MSDN Forums (for example, this post and this post). I encourage you to read some of these posts and others that are included as links within them before making your setup packaging decision for the VC 8.0 runtime files.
<update date="1/24/2006"> Added information about the IA64 version of the VC redist package. </update>
<update date="11/19/2009"> Added information about VC++ 2005 SP1 and VC++ 2005 SP1 ATL Security Update packages. </update>
<update date="2/11/2015"> Added a link to a knowledge base article to help clarify that post-Vista versions of Windows do not include VC++ runtime files as OS components. </update>
I had the same problem to detect if the VC8 runtime is already installed.
When I analyzed the wrapped msi from vcredist_x86.exe with Orca I found a registry key HKLM\SOFTWARE\Microsoft\DevDiv\VC\Servicing\8.0\RED\1033\Install. I use this key to determine if the VC8 runtime is on the box.
Is this way OK or is it unrecommended?
Hi Christian - Yes, I see that registry value in the MSI for the vcredist_x86.exe package. It should also be safe to use that key/value to determine whether or not the VC 8.0 runtime redist package is installed on a user's system.
This approach has the same caveat as the product code-based algorithm that I described in the main post - there may be cases where this registry key doesn't exist, but the user already has the VC runtimes on their system.
I posted an item last week that described how to detect the presence of the Visual C++ 8.0 runtime files
A small thing about installing the vc runtime to a local directory (aka applocal install).
The vc_redist installs to the sxs cache and has to be installed per-machine.
The load order for side-by-side dlls actually loads the sxs dlls in preference to the applocal dlls. So when you install the original vc 2005 dlls in your directory (applocal) and install the vc2005sp1 redist (sxs cache), your app will load the vc2005sp1 dlls.
Question: I have built an application in Visual Studio 2005 that depends on the VC 8.0 runtime files
I have previously posted a few items about deploying the Visual C++ 8.0 runtime redistributable packages
I previously wrote a blog post about updated versions of the Visual C++ 8.0 runtime files that shipped
Question: I saw a couple of previous blog posts that you wrote about how to detect the presence of the
Question: You previously posted a list of command line switches to perform silent and unattended installations
For the Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update (x86) the Product Code is:
According to this article support.microsoft.com/.../en-us (and report from this comment stackoverflow.com/.../11172939), the VC runtime is no longer considered a system file, and your note "It also does not cover the case of Windows Vista, where the VC 8.0 runtime files are installed as part of the OS." might be misleading for those expecting the runtime on any newer Windows versions.
Hi TLama - Thanks for posting this clarification. I wrote this blog post back in 2007 before the changes that you reference about the VC runtime files no longer being considered system files. I'll go back and update the text of the blog post as well to avoid potential confusion on post-Vista versions of Windows.