Visual Studio 2005 installs Visual C++ libraries as shared side-by-side assemblies. By default, all applications built with Visual Studio 2005 are built as isolated applications with a manifest either embedded as a resource, or accompanying the final binary as an external file. In order to ensure that your Visual C++ application will run on a computer without Visual C++ installed, you may have to redistribute Visual C++ assemblies with your application and ensure they are installed on the target computer.

There are three ways to redistribute Visual C++ DLLs:

1. Using Visual C++ Redistributable Merge Modules to install a particular Visual C++ library as shared side-by-side assemblies into the native assembly cache (WinSxS folder). This is the primary recommended way for redistributing Visual C++ libraries. Access to this folder requires that the installer application be run by a user with administrative rights. For more information please see Redistributing Using Merge Modules. An example of this deployment may be found in How to: Deploy a Setup and Deployment Project.

2. Using Visual C++ Redistributable Package (VCRedist_x86.exe, VCRedist_x64.exe, VCRedist_ia64.exe) to install all Visual C++ libraries as shared side-by-side assemblies into the native assembly cache (WinSxS folder). This package is installed by Visual Studio into %WindowsSdkDir%\Bootstrapper\Packages\ folder and can also be downloaded from the Microsoft download site Microsoft Visual C++ 2005 Redistributable Package (x86). Redistributing Visual C++ libraries using this package is recommended for applications built with Visual C++ Express and for cases when deployment of all Visual C++ libraries at once is desirable. For an example of how to use this package please see How to: Deploy using XCopy.

3. Install a particular Visual C++ assembly as a private assembly for the application using files provide in the Program Files\Microsoft Visual Studio 8\VC\Redist directory. This way is recommended to enable installation of applications by users who do not have administrative rights or when it should be possible to run an application from a share. For an example, please see How to: Deploy using XCopy.

Note:
On Windows Server 2000, the only recommended and supported way to redistribute Visual C++ libraries is by using Redistributable Merge Modules.

When installing Visual C++ libraries using redistributable merge modules, the assemblies are deployed as shared side-by-side assemblies into the native assembly cache (WinSxS folder). Access to this folder requires that the installer application be run by a user with administrative rights.

If an installation is run by a user who does not have administrative rights, the installation fails to deploy the Visual C++ assemblies and the application will not run. Also, some products may allow installation on a per-user basis, but merge modules install libraries into shared locations and impact all users of the system. In both these and similar scenarios, the supported technique is to install the required assemblies as private side-by-side assemblies for a particular user's application.

With this technique, it is enough to copy a folder with DLLs and manifests for dependent assemblies to the application's local folder. The operating system's loader, when executing the application, still looks for dependent assemblies in the WinSxS folder first; however when a corresponding assembly cannot be found, the loader loads a private assembly from this sub-directory.

Incorrect redistribution of Visual C++ libraries may result in run-time errors during execution of an application that depends on them. A list of potential errors and resolutions to these errors can be found in Troubleshooting C/C++ Isolated Applications and Side-by-side Assemblies.

It is not supported to redistribute C/C++ applications that are built without a manifest. Visual C++ libraries cannot be used by C/C++ applications without a manifest binding the application to these libraries. All C/C++ binaries built in Visual C++ 2005 have to include a manifest describing their dependencies on Visual C++ libraries. This is the default setup of projects in Visual Studio and the default behavior of the linker building the final binary from object code.

It is recommended in all cases that the manifest be internal. However, in the case of an EXE file, the manifest can be external (this scenario is supported but not recommended).

Applications that expect dependent DLLs to be present in either the application-local folder or in a folder indicated by an environment variable may also be vulnerable to security-related exploits. It is also more difficult to service such applications after they have been deployed.

It is not recommended to redistribute C/C++ applications that statically link to Visual C++ libraries. It is often mistakenly assumed that by statically linking your program to Visual C++ libraries it is possible to significantly improve the performance of an application. However the impact on performance of dynamically loading Visual C++ libraries is insignificant in almost all cases. Furthermore, static linking does not allow for servicing the application and its dependent libraries by either the application's author or Microsoft. For example, consider an application that is statically linked to a particular library, running on a client computer with a new version of this library. The application still uses code from the previous version of this library, and does not benefit from library improvements, such as security enhancements. Authors of C/C++ applications are strongly advised to think through the servicing scenario before deciding to statically link to dependent libraries, and use dynamic linking whenever possible.

Concepts

Other Resources