Exemples de scénarios de déploiement

Article
08/21/2008

Mise à jour : novembre 2007

Supposons que nous disposions de MyApplication.exe et MyLibrary.DLL, tous deux générés avec MFC. MyApplication.exe dépend de MyLibray.DLL ; toutes deux utilisent MFC dans une DLL partagée et toutes deux peuvent être des fichiers binaires natifs ou mixtes (/clr). Dans le cas le plus simple, tous deux sont générés par l'Assistant sans modification des paramètres par défaut. Les exemples de cette section décrivent comment déployer cette application sur un autre ordinateur où Visual Studio n'est pas installé. Cette section traite principalement du déploiement de la version release de l'application ; toutefois, les modifications nécessaires pour déployer la version debug d'une application sont signalées.

Remarque :
La redistribution de programmes Visual C++ debug n'est pas autorisée par ce CLUF. Toutefois, vous pouvez les déployer temporairement à des fins de débogage. Consultez les termes et conditions de la licence logicielle (CLUF) de Visual Studio 2008.

Configuration initiale

Il y a trois ordinateurs à prendre en compte dans ce scénario.

L'ordinateur de développement est celui sur lequel l'application est générée. Visual Studio 2005 (STD, PRO ou TS) y est installé.

Les deux ordinateurs cibles du déploiement ne disposent pas de Visual Studio 2005 installé. L'ordinateur de déploiement cible n 1 exécute un système d'exploitation qui prend en charge la liaison basée sur un manifeste d'applications avec leurs dépendances (Windows XP Édition familiale, Windows XP Professionnel, Windows Server 2003, Windows Vista). L'ordinateur de déploiement cible 2 exécute un système d'exploitation sans cette prise en charge (Windows 2000).

Le but est de générer l'application sur l'ordinateur de développement, puis de la déployer sur les deux ordinateurs cibles et de l'exécuter.

Préparation

Lorsque vous avez généré un fichier binaire Visual C++ qui va s'exécuter sur un autre ordinateur, vous devez déterminer les DLL dont il dépend. L'outil Dependency Walker va vous être très utile. Dans ce scénario, vous devez considérer les DLL Visual C++, en particulier CRT et MFC. Si vous ouvrez la version debug de MyApplication.exe dans Visual Studio et parcourez ses ressources, vous pouvez voir la ressource RT_MANIFEST. Il s'agit du manifeste incorporé dans le fichier binaire. Si vous l'exportez et l'ouvrez en tant que fichier XML, vous pouvez voir les éléments suivants :

<?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>

Cela signifie que cette application dépend de ces assemblys :

Assembly Microsoft.VC90.DebugCRT, version 9.0.xxxxx.yy pour x86
Assembly Microsoft.VC90.DebugMFC, version 9.0.xxxxx.yy pour x86
Assembly Microsoft.Windows.Common-Controls, version 6.0.0.0 pour x86

Dans la version finale du fichier binaire, vous pourrez voir ceci :

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

Cela signifie que cette application dépend de ces assemblys :

Assembly Microsoft.VC90.CRT, version 9.0.xxxxx.yy pour x86
Assembly Microsoft.VC90.MFC, version 9.0.xxxxx.yy pour x86
Assembly Microsoft.Windows.Common-Controls, version 6.0.0.0 pour x86

Vous pouvez voir de manifestes semblables dans MyLibrary.dll, pour les deux versions debug et release. Notez que l'ID du manifeste est 1 pour un EXE, 2 pour une DLL. De même, si le manifeste n'est pas incorporé dans le fichier binaire, il est stocké en tant que <binaryname>.<extension>.manifest et a le même contenu.

Remarque :
Visual Studio 2005 ne prend pas en charge la génération d'applications C++ sans manifeste ni la liaison avec les bibliothèques Visual C++ selon la manière précédente qui utilise %PATH%. De plus, les DLL Visual C++ sont capables de le détecter, empêchent la DLL de charger, signalent que ce scénario n'est pas pris en charge et indiquent ce qui doit être modifié. N'utilisez pas /manifest:no ou supprimez le manifeste.

Visual Studio 2005 ne prend pas en charge la génération d'applications C++ sans manifeste ni la liaison avec les bibliothèques Visual C++ selon la manière précédente qui utilise %PATH%. De plus, les DLL Visual C++ sont capables de le détecter, empêchent la DLL de charger, signalent que ce scénario n'est pas pris en charge et indiquent ce qui doit être modifié. N'utilisez pas /manifest:no ou supprimez le manifeste.

Méthodes de déploiement

Dans cet exemple, vous installez MyApplication.exe dans un dossier %TARGET% qui peut être spécifié par le client lors de l'installation. MyLibrary.dll sera installée dans %TARGET%\MyLibrary, et \MyLibrary sera ajoutée au chemin d'accès.

Nous examinerons deux méthodes servant à déployer des applications VC++ :

Génération d'un package d'installation à l'aide d'un projet de configuration et de déploiement.
Déploiement XCopy.

Pour chaque méthode, nous explorerons deux scénarios :

Déploiement des bibliothèques Visual C++ en tant qu'assemblys partagés.
Déploiement des bibliothèques Visual C++ en tant qu'assemblys privés.

Dans le scénario 1, vous ne disposez que d'une seule copie des DLL Visual C++ dans le dossier WinSxS. Dans le scénario 2, vous disposez de deux copies des DLL Visual C++, installées dans les dossiers locaux EXE et DLL de l'application.

Remarque :
Le scénario 2 n'est pas pris en charge par Windows 2000 en raison des problèmes posés par le déploiement dans les dossiers locaux de l'application en cas de maintenance.

Voir aussi

Tâches

Comment : déployer un projet d'installation et de déploiement

Comment : déployer à l'aide de XCopy

Concepts

Exemples de déploiement