Microsoft Visual C++ 2005 Redistributable File Location

[Gene Cryder]

Whenyou deploy an application, you must also deploy the files that are required to support it. If any of these files are provided by Microsoft, check whether you're permitted to redistribute them. You'll find a link to the Visual Studio license terms in the IDE. Use the License terms link in the About Microsoft Visual Studio dialog box. Or, download the relevant EULAs and licenses from the Visual Studio License Directory.

To view the "REDIST list" that's referenced in the "Distributable Code" section of the Visual Studio 2022 Microsoft Software License Terms, see Distributable code files for Microsoft Visual Studio 2022

To view the "REDIST list" that's referenced in the "Distributable Code" section of the Visual Studio 2019 Microsoft Software License Terms, see Distributable Code Files for Microsoft Visual Studio 2019

To view the "REDIST list" that's referenced in the "Distributable Code" section of the Visual Studio 2017 Microsoft Software License Terms, see Distributable Code Files for Microsoft Visual Studio 2017.

To view the "REDIST list" that's referenced in the "Distributable Code" section of the Visual Studio 2015 Microsoft Software License Terms, see Distributable Code Files for Microsoft Visual Studio 2015.

The easiest way to locate the redistributable files is by using environment variables set in a developer command prompt. In Visual Studio 2022, the redistributable files are in the %VCINSTALLDIR%Redist\MSVC\v143 folder. In the latest version of Visual Studio 2019, you'll find the redistributable files in the %VCINSTALLDIR%Redist\MSVC\v142 folder. In both Visual Studio 2017 and Visual Studio 2019, they're also found in %VCToolsRedistDir%. In Visual Studio 2015, these files can be found in %VCINSTALLDIR%redist\, where is the locale of the redistributable packages.

The Visual C++ Redistributable Packages install and register all Visual C++ libraries. If you use one, run it as a prerequisite on the target system before you install your application. We recommend that you use these packages for your deployments because they enable automatic updating of the Visual C++ libraries. For an example about how to use these packages, see Walkthrough: Deploying a Visual C++ Application By Using the Visual C++ Redistributable Package.

Each Visual C++ Redistributable package checks for the existence of a more recent version on the machine. If a more recent version is found, the package won't get installed. In Visual Studio 2015 or later, Redistributable packages display an error message stating that setup failed. If a package is run by using the /quiet flag, no error message is displayed. In either case, an error is logged by the Microsoft installer, and an error result is returned to the caller. In Visual Studio 2015 and later, you can avoid this error by checking the registry to find out if a more recent version is installed. The current installed version number is stored in the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\x86 key. The version number is 14.0 for Visual Studio 2015, 2017, 2019, and 2022 because the latest Redistributable is binary compatible with previous versions back to 2015. The key is arm64, x86, or x64 depending on the installed vcredist versions for the platform. (You need to check under the Wow6432Node subkey only if you're using Regedit to view the version of the installed x86 package on an x64 platform.) The version number is stored in the REG_SZ string value Version and also in the set of Major, Minor, Bld, and Rbld REG_DWORD values. To avoid an error at install time, you must skip installation of the Redistributable package if the currently installed version is more recent.

The Visual C++ Redistributable supports several command-line options. The /?, /h, or /help options display a pop-up dialog that lists the available options. You may specify /install to install, /repair to repair, or /uninstall to uninstall the Redistributable. The /layout option copies the complete contents of the Redistributable in the current directory. By default, the Redistributable installs its contents and prompts the user for information and whether to restart after installation. You can specify the /passive option, which displays progress, but doesn't otherwise require user interaction. You can also specify a /quiet option, which doesn't display any UI or require any user interaction. The /norestart option suppresses any attempts to restart. By default, a log file is created in %TEMP%. You can use /log filename.txt to log to a specific file.

Merge modules (.msm files) for Visual C++ Redistributable files are deprecated. We don't recommend you use them for application deployment. Instead, we recommend central deployment of the Visual C++ Redistributable package. Central deployment by a Redistributable package makes it possible for Microsoft to service runtime library files independently. And, an uninstall of your app can't affect other applications that also use central deployment. When you use a Redistributable package for central deployment, you aren't responsible for tracking and maintaining the runtime libraries. Otherwise, an update to the runtime library files requires you to update and redeploy your .msi installer. Your app could be vulnerable to bugs or security issues until you do.

Redistributable merge modules must be included in the Windows Installer package (or similar installation package) that you use to deploy your application. For more information, see Redistributing by using merge modules. For an example see Walkthrough: Deploying a Visual C++ application by using a setup project.

It's also possible to directly install the Redistributable DLLs in the application local folder. The application local folder is the folder that contains your executable application file. For servicing reasons, we don't recommend you use this installation location.

If Windows can't find one of the Redistributable library DLLs required by your application, it may display a message similar to: "This application has failed to start because library.dll was not found. Reinstalling the application may fix this problem."

To resolve this kind of error, make sure your application installer builds correctly. Verify that the Redistributable libraries get deployed correctly on the target system. For more information, see Understanding the Dependencies of a Visual C++ Application.

The layout of the compiler tools on the disk in VS 2015 reflects decisions made years ago. When we shipped Visual Studio .NET in 2002, we shipped compilers that targeted only the x86 architecture. The x64 and Itanium architectures had only recently been announced when development of Visual Studio .NET started. The layout of the compiler on-disk reflected a world where x86 was the only compiler you would need.

When we introduced support for the Itanium and x64 architectures we added the compilers where it made sense: in the bin directory. We already had a compiler for x86 in the bin directory, so we added subdirectories x86_ia64 and x86_amd64 for compilers that run on x86 and target 64-bit platforms as well as an amd64 directory for compilers that run on x64.

The bin directory is the only one with a set of HostXXX directories. This is because the executables need to run on the host. The include directory, which contains only source files, is specific to neither the host nor the target. The lib directory is specific to only the target architecture. Likewise, many of the tools in the Auxiliary directory are specific to the target architecture but not to the host.

We hope you can see that there are a lot of benefits to refreshing our compiler toolset layout on disk. As Visual C++ grows to include more scenarios like Android and iOS targeting we need to include more compiler toolsets. And as we release our tools more frequently we increase the chance that our developers might want to have multiple versions of the Visual C++ compiler tools installed side-by-side. This new layout is flexible and extensible and should (hopefully!) serve us for many years to come.

Please, please, please check out the scripts that you use and make sure you can migrate them to use the new layout. We want to know if you run into any problems. We want to know how hard the migration experience was for your code. Please leave comments on this blog post or send mail directly to our team at visu...@microsoft.com.

One last note: a lot of build systems need to find the default version of the Visual C++ tools. When you install Visual Studio it creates a file, %VCINSTALLDIR%\Auxiliary\Build\Microsoft.VCToolsVersion.default.txt, that contains the version string for the default toolset installed with VS. In a typical Preview 5 installation, %VCINSTALLDIR% would point to %Program Files(x86)%\Microsoft Visual Studio\Visual Studio 15.0\Common7\IDE\VisualCpp.

Programs designed with Visual Studio may require a specific version of the Microsoft Visual C++ Redistributable to run. The requirement resulted in the installation of a large number of Visual C++ Redistributable packages on Windows PCs.

It is not uncommon to see multiple Microsoft Visual C++ Redistributables on a system that were installed by software programs, through updates, e.g. security updates, or manually by the system administrator.

Redistributables are stored in a central location so that any program installed on the system may access the files if required. You can check out our detailed guide on Visual C++ Redistributables here for additional details.

Microsoft changed the system significantly with the release of the Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019. A baseline image is provided for these redistributable packages so that it is no longer necessary to install different versions separately on target systems.

From Visual Studio .NET through Visual Studio 2013, each major release of the C++ compiler and tools has included a new, standalone version of the Microsoft C Runtime (CRT) library. These standalone versions of the CRT were independent from, and to various degrees, incompatible with each other. For example, the CRT library used by Visual Studio 2012 was version 11, named msvcr110.dll, and the CRT used by Visual Studio 2013 was version 12, named msvcr120.dll. Beginning in Visual Studio 2015, this is no longer the case. Visual Studio 2015 and later versions of Visual Studio all use one Universal CRT.

3a8082e126