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 two recommended ways to redistribute Visual C++ DLLs. First, you can use Visual C++ Redistributable Merge Modules to install Visual C++ assemblies as shared side-by-side assemblies. Alternatively, you can 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.

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

When installing Visual C++ assemblies 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. More details on this can be found in Redistributing Visual C++ Files.

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 library. All C/C++ programs 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.

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.

Other Resources