Scenarios for Deployment Examples
Let us assume we have MyApplication.exe and MyLibrary.DLL, both built with MFC. MyApplication.exe depends on MyLibrary.DLL, both use MFC in a shared DLL, and both can be native or mixed (/clr) binaries. In the simplest case, both are generated by the wizard with no change to default settings. The examples in this section describe how to deploy this application to another computer where Visual Studio is not installed. This section primarily covers deploying the release version of the application; however, changes required for deploying the debug version of an application are pointed out.
Note
Redistributing debug Visual C++ programs is not permitted by the Microsoft Software License Terms for Visual Studio 2008. However, you may deploy them temporarily for debugging purposes.
Initial setup
There are three computers to consider in this scenario.
The development computer is the one on which the application is built. It has Visual Studio 2005 (STD, PRO, or TS) installed.
The two deployment target computers do not have Visual Studio 2005 installed. Deployment target 1 is a computer running an operating system that supports manifest-based binding of applications to their dependencies (Windows XP Home Edition, Windows XP Professional, Windows Server 2003, Windows Vista). Deployment target 2 runs an operating system without such support (Windows 2000).
The goal is to build the application on the development computer, deploy it to the two target computers, and run it.
Preparation
When you have built a Visual C++ binary that is going to be run on another computer, you need to determine which DLLs this binary depends on. A useful tool for this is Dependency Walker. In this scenario, you must consider the Visual C++ DLLs, in particular CRT and MFC. If you open the debug version of MyApplication.exe in Visual Studio and browse through its resources, you can see the RT_MANIFEST resource. This is the manifest embedded inside the binary. If you export it and open as an XML file, you see the following:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.DebugCRT" version="9.0.xxxxx.yy" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.DebugMFC" version="9.0.xxxxx.yy" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
This means that this application depends on these assemblies:
Assembly Microsoft.VC90.DebugCRT, version 9.0.xxxxx.yy for x86
Assembly Microsoft.VC90.DebugMFC, version 9.0.xxxxx.yy for x86
Assembly Microsoft.Windows.Common-Controls, version 6.0.0.0 for x86
In the release binary, you will see this:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.xxxxx.yy" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.MFC" version="9.0.xxxxx.yy" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
This means that this application depends on these assemblies:
Assembly Microsoft.VC90.CRT, version 9.0.xxxxx.yy for x86
Assembly Microsoft.VC90.MFC, version 9.0.xxxxx.yy for x86
Assembly Microsoft.Windows.Common-Controls, version 6.0.0.0 for x86
You would see similar manifests in MyLibrary.dll, both for debug and release. Note that the manifest ID is 1 for an EXE, 2 for a DLL. Also, if the manifest is not embedded in the binary, it is stored as <binaryname>.<extension>.manifest and has the same content.
Note
Visual Studio 2005 does not support building C++ applications without a manifest and binding to Visual C++ libraries the old way using %PATH%. Moreover, Visual C++ DLLs can detect this, prevent the DLL from loading and report the unsupported scenario and the necessary changes. Do not use /manifest:no or delete the manifest.
Deployment methods
In this example, you will install MyApplication.exe to a folder %TARGET% that can be specified by the customer during installation. MyLibrary.dll will be installed in %TARGET%\MyLibrary, and \MyLibrary added to the path.
We will examine two methods to deploy Visual C++ applications:
Building a setup package using a Setup and Deployment Project.
XCopy Deployment.
For each method, we will explore two scenarios:
Deploying Visual C++ libraries as shared assemblies.
Deploying Visual C++ libraries as private assemblies.
In scenario 1, there is only one copy of the Visual C++ DLLs in the WinSxS folder. In scenario 2, you will have two copies of the Visual C++ DLLs, installed in the application EXE's and DLL's local folders.
Note
Scenario 2 is not supported on Windows 2000 because deployment in application-local folders creates problems when it comes to servicing.
See Also
Tasks
How to: Deploy a Setup and Deployment Project