Choix d'une méthode de déploiement

Mise à jour : novembre 2007

Dans la plupart des cas, le déploiement d'applications Visual C++ s'effectue avec le déploiement Windows Installer. Pour plus d'informations sur les méthodes de déploiement prises en charge par Visual Studio et leurs alternatives, consultez Choix d'une stratégie de déploiement et Autres solutions de déploiement. Le déploiement ClickOnce pour les applications natives Visual C++ n'est pas pris en charge dans Visual Studio 2005 ; toutefois, il est possible de déployer des applications Visual C++ via ClickOnce sur la ligne de commande. Pour plus d'informations, consultez Déploiement de ClickOnce pour les applications Visual C++.

Visual Studio 2005 installe des bibliothèques Visual C++ en tant qu'assemblys côte à côte partagés. Par défaut, toutes les applications générées avec Visual Studio 2005 le sont en tant qu'applications isolées avec un manifeste incorporé comme une ressource ou accompagnant le fichier binaire final comme un fichier externe. Pour s'assurer que votre application Visual C++ s'exécute sur un ordinateur sans Visual C++ installé, vous devrez peut-être redistribuer les assemblys Visual C++ avec votre application et veiller à ce qu'ils soient installés sur l'ordinateur cible.

Il existe trois façons de redistribuer les DLL Visual C++ :

  1. Modules de fusion de Visual C++ Redistributable pour installer une bibliothèque Visual C++ particulière comme assemblys côte à côte partagés dans le cache d'assembly natif (dossier WinSxS). Il s'agit de la principale solution recommandée pour redistribuer les bibliothèques Visual C++. L'accès à ce dossier requiert l'exécution du programme d'installation par un utilisateur disposant de droits d'administration. Pour plus d'informations, consultez Redistribution à l'aide de modules de fusion. Un exemple de ce déploiement se trouve dans Comment : déployer un projet d'installation et de déploiement.

  2. Visual C++ Redistributable Package (VCRedist_x86.exe, VCRedist_x64.exe, VCRedist_ia64.exe) pour installer toutes les bibliothèques Visual C++ comme assemblys côte à côte partagés dans le cache d'assembly natif (dossier WinSxS). Ce package est installé par Visual Studio dans le dossier %WindowsSdkDir%\Bootstrapper\Packages\ et peut également être téléchargé depuis le site de téléchargement Microsoft Microsoft Visual C++ 2005 Redistributable Package (x86). La redistribution des bibliothèques Visual C++ à l'aide de ce package est recommandé pour les applications développées avec Visual C++ Express et pour les cas où le déploiement simultané de toutes les bibliothèques Visual C++ est souhaitable. Pour obtenir un exemple illustrant l'utilisation de ce package, consultez Comment : déployer à l'aide de XCopy.

  3. Installez un assembly Visual C++ particulier comme assembly privé de l'application à l'aide des fichiers fournis dans le répertoire Program Files\Microsoft Visual Studio 8\VC\Redist. Cette solution est recommandée pour activer l'installation d'applications par les utilisateurs qui n'ont pas de droits d'administration ou lorsqu'il doit être possible d'exécuter une application à partir d'un partage. Pour obtenir un exemple, consultez Comment : déployer à l'aide de XCopy.

Remarque :

Sur Windows Server 2000, la seule méthode recommandée et prise en charge pour redistribuer des bibliothèques Visual C++ consiste à utiliser des modules de fusion redistribuables.

Lors de l'installation de bibliothèques Visual C++ qui utilisent des modules de fusion redistribuables, les assemblys sont déployés en tant qu'assemblys côte à côte partagés dans le cache d'assembly natif (dossier WinSxS). L'accès à ce dossier requiert l'exécution du programme d'installation par un utilisateur disposant de droits d'administration.

Si une installation est exécutée par un utilisateur qui ne dispose pas de droits d'administration, le déploiement des assemblys Visual C++ n'aura pas lieu et l'application ne s'exécutera pas. Par ailleurs, certains produits peuvent autoriser l'installation sur une base individuelle, mais les modules de fusion installent les bibliothèques dans des emplacements partagés et affectent tous les utilisateurs du système. Dans ces scénarios et dans d'autres scénarios similaires, la technique prise en charge consiste à installer les assemblys requis comme des assemblys côte à côte privés de l'application d'un utilisateur spécifique.

Avec cette technique, il suffit juste de copier un dossier contenant les DLL et les fichiers manifeste des assemblys dépendants dans le dossier local de l'application. Lors de l'exécution de l'application, le chargeur du système d'exploitation commence par chercher les assemblys dépendants dans le dossier WinSxS ; mais s'il manque un assembly correspondant, il charge un assembly privé à partir de ce sous-répertoire.

La redistribution non valide de bibliothèques Visual C++ peut provoquer des erreurs pendant l'exécution d'une application qui en dépend. La liste des erreurs potentielles et de leur résolution se trouve dans Dépannage d'applications isolées C/C++ et d'assemblys côte à côte.

Il n'est pas possible de redistribuer des applications C/C++ qui sont générées sans manifeste. Les bibliothèques Visual C++ ne peuvent pas être utilisées par les applications C/C++ sans un manifeste qui lie l'application à ces bibliothèques. Tous les binaires C/C++ générés dans Visual C++ 2005 doivent inclure un manifeste décrivant leurs dépendances vis-à-vis des bibliothèques Visual C++. Il s'agit de la configuration par défaut des projets dans Visual Studio et du comportement par défaut de l'éditeur de liens générant le fichier binaire final du code objet.

Il est recommandé dans tous les cas que le manifeste soit interne. Cependant, le manifeste peut être externe (ce scénario est pris en charge mais n'est pas recommandé) dans le cas d'un fichier EXE.

Les applications qui s'attendent à la présence de DLL dépendantes dans le dossier local de l'application ou dans un dossier indiqué par une variable d'environnement peuvent également être vulnérables aux attaques de sécurité. Il est également plus difficile d'assurer la maintenance de ces applications une fois qu'elles ont été déployées.

Il n'est pas recommandé de redistribuer des applications C/C++ qui sont statiquement liées aux bibliothèques Visual C++. C'est une erreur courante de penser qu'en liant statiquement votre programme aux bibliothèques de Visual C++, il est possible d'améliorer sensiblement les performances d'une application. Toutefois, l'impact sur les performances du chargement dynamique des bibliothèques Visual C++ est insignifiant dans la plupart des cas. En outre, la liaison statique ne permet pas d'assurer la maintenance de l'application et de ses bibliothèques dépendantes par l'auteur de l'application ou Microsoft. Considérons, par exemple, une application liée statiquement à une bibliothèque donnée, s'exécutant sur un ordinateur client avec une nouvelle version de cette bibliothèque. L'application utilise toujours le code de la version antérieure de cette bibliothèque et ne bénéficie pas des améliorations de la bibliothèque, par exemple les améliorations de sécurité. Il est vivement recommandé aux auteurs d'applications C/C++ de réfléchir à un scénario de maintenance avant d'opter pour la liaison statique avec les bibliothèques dépendantes, et d'utiliser si possible la liaison dynamique.

Ajouts de la communauté

Afficher: