Export (0) Print
Expand All

Scenarios for Deployment Examples 

Let us assume we have MyApplication.exe and MyLibrary.DLL, both built with MFC. MyApplication.exe depends on MyLibray.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.

NoteNote

Redistributing debug VC++ programs is not permitted by the EULA. You can only do this for testing purposes internally. See the EULA for Visual Studio 2005.

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 98, Windows 98 Second Edition, Windows Millennium Edition, 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.VC80.DebugCRT" version="8.0.50727.42" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.DebugMFC" version="8.0.50727.42" 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.VC80.DebugCRT, version 8.0.50727.42 for x86

  • Assembly Microsoft.VC80.DebugMFC, version 8.0.50727.42 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.VC80.CRT" version="8.0.50727.42" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.42" 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.VC80.CRT, version 8.0.50727.42 for x86

  • Assembly Microsoft.VC80.MFC, version 8.0.50727.42 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.

NoteNote

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 VC++ applications:

  1. Building a setup package using a Setup and Deployment Project.

  2. XCopy Deployment.

For each method, we will explore two scenarios:

  1. Deploying Visual C++ libraries as shared assemblies.

  2. 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.

NoteNote

Scenario 2 is not supported on Windows 98, Windows 98 Second Edition, Windows Millennium Edition, Windows 2000 because deployment in application-local folders creates problems when it comes to servicing.

See Also

Community Additions

ADD
Show:
© 2014 Microsoft