Choosing a deployment method of Visual C ++ applications

Http://msdn.microsoft.com/en-us/library/ms235316.aspx

 

In most cases deployment of Visual C ++ applications is done with Windows Installer deployment. for more information on deployment methods supported within Visual Studio and alternatives, see choosing a deployment strategy and deployment alternatives. clickonce deployment for Visual C ++ native applications is not supported in Visual Studio 2010; however, it is possible to deploy visual c ++ applications via clickonce on the command line. for more information, see clickonce deployment for Visual C ++ applications.

Visual c ++ libraries are shared DLLs

Visual Studio 2010 instils visual c ++ libraries as shared DLLs in the % WINDIR %/system32 directory. 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 ++ DLLs with your application and ensure they are installed on the target computer.

Redistributing visual c ++ Libraries

There are three ways to redistribute visual c ++ DLLs:

• We recommend that you use the Visual C ++ redistributable package (Vcredist_x86.exe,Vcredist_x64.exe,Vcredist_ia64.exe) To install all visual C ++ libraries as shared DLLs in % WINDIR %/system32. Visual Studio installthis package in the % windowssdkdir %/bootstrapper/packages folder. you can also download it from the Microsoft download center. for an example of how to use this package, see Walkthrough: deploying a visual C ++ application by using the Visual C ++ redistributable package.

• Use Visual C ++ redistributable merge modules to install a particle visual c ++ library as shared DLLs in % WINDIR %/system32. 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 Walkthrough: deploying a visual C ++ application by using a setup project.

• Install a particle visual c ++ DLL in the same folder as the application by using files provide in the program files/Microsoft Visual Studio 10.0/VC/redist directory. this way is recommended to enable installation of applications by users who do not have administrative rights or when it shoshould be possible to run an application from a share.

When installing visual c ++ libraries using redistributable merge modules, the DLLs are deployed as shared DLLs in % WINDIR %/system32. 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 ++ DLLs 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 DLLs in the directory of a particle user's application.

With this technique, it is enough to copy DLLs to the application's local folder. the operating system's loader, when executing the application, uses the search order described in LoadLibraryEx.

Incorrect redistribution of Visual C ++ libraries may result in run-time errors during execution of an application that depends on them

Prefer Dynamic Linking over static linking

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 particle 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 stronugly advised to think through the servicing scenario before deciding to statically link to dependent libraries, and use Dynamic Linking whenever possible.