Scénarios d’installation de VSPackage
Il est important de concevoir votre programme d’installation VSPackage pour une flexibilité. Par exemple, vous devrez peut-être publier un correctif de sécurité à l’avenir, ou modifier une stratégie métier nécessitant une prise en charge approfondie du contrôle de version côte à côte.
Dans la prise en charge de plusieurs versions de Visual Studio, vous pouvez lire les avantages et les problèmes liés à la prise en charge des installations côte à côte de Visual Studio avec des installations partagées ou côte à côte de votre VSPackage. En bref, les VSPackages côte à côte vous offrent la plus grande flexibilité pour prendre en charge de nouvelles fonctionnalités de Visual Studio.
Les scénarios abordés dans cette rubrique ne sont pas vos seuls choix, mais ils sont présentés comme des meilleures pratiques suggérées.
Composants, confidentialité et partage
Rendre vos composants indépendants
Une fois que vous avez identifié et renseigné un composant, affectez un GUIDcomposant et déployez le composant, vous ne pouvez pas modifier sa composition. Si vous modifiez la composition d’un composant, le composant résultant doit être un nouveau composant avec un nouveau GUIDcomposant . Compte tenu de ces faits, la plus grande flexibilité de contrôle de version est offerte en rendant chaque composant indépendant et autonome unité. Pour plus d’informations sur les règles régissant les composants, consultez Modification du code du composant et que se passe-t-il si les règles de composant sont rompues ?.
Ne pas mélanger les ressources partagées et privées dans un composant
Le comptage de références se produit au niveau du composant. Par conséquent, le mélange de ressources partagées et privées dans un composant rend impossible la mise à jour des ressources privées, telles qu’un fichier exécutable, sans remplacer également les ressources partagées. Ce scénario crée des problèmes de compatibilité descendante et vous empêche de créer une fonctionnalité côte à côte.
Par exemple, les valeurs de Registre utilisées pour inscrire votre VSPackage auprès du Kit de développement logiciel (SDK) Visual Studio doivent être conservées dans un composant distinct de celui utilisé pour inscrire votre VSPackage auprès de Visual Studio. Les fichiers partagés ou les valeurs de Registre passent dans un autre composant.
Scénario 1 : VSPackage partagé
Dans ce scénario, un VSPackage partagé (un seul binaire qui prend en charge plusieurs versions de Visual Studio est fourni dans un package Windows Installer. L’inscription auprès de chaque version de Visual Studio est contrôlée par les fonctionnalités sélectionnables par l’utilisateur. Cela signifie également qu’en cas d’affectation à des fonctionnalités distinctes, chaque composant peut être sélectionné individuellement pour l’installation ou la désinstallation, en plaçant l’utilisateur dans le contrôle de l’intégration de VSPackage dans différentes versions de Visual Studio. (Voir Fonctionnalités Windows Installer pour plus d’informations sur l’utilisation des fonctionnalités dans les packages Windows Installer.)
Comme illustré dans l’illustration, les composants partagés font partie de la fonctionnalité Feat_Common, qui est toujours installée. En rendant les fonctionnalités Feat_VS2002 et Feat_VS2003 visibles, les utilisateurs peuvent choisir au moment de l’installation dans quelles versions de Visual Studio ils veulent que VSPackage s’intègre. Les utilisateurs peuvent également utiliser le mode de maintenance Windows Installer pour ajouter ou supprimer des fonctionnalités, qui, dans ce cas, ajoute ou supprime les informations d’inscription VSPackage de différentes versions de Visual Studio.
Remarque
La définition de la colonne d’affichage d’une fonctionnalité sur 0 la masque. Une valeur de colonne de bas niveau, telle que 1, garantit qu’elle sera toujours installée. Pour plus d’informations, consultez INSTALLLEVEL Property and Feature Table.
Scénario 2 : Mise à jour VSPackage partagée
Dans ce scénario, une version mise à jour du programme d’installation vsPackage dans le scénario 1 est fournie. Par souci de discussion, la mise à jour ajoute la prise en charge de Visual Studio, mais il peut également s’agir d’un correctif de sécurité plus simple ou d’un service pack de résolution de bogues. Les règles de Windows Installer pour l’installation de composants plus récents nécessitent que les composants inchangés déjà sur le système ne soient pas recopiés. Dans ce cas, un système avec la version 1.0 déjà présente remplacera le composant mis à jour Comp_MyVSPackage.dll et permet aux utilisateurs de choisir d’ajouter la nouvelle fonctionnalité Feat_VS2005 avec son composant Comp_VS2005_Reg.
Attention
Chaque fois qu’un VSPackage est partagé entre plusieurs versions de Visual Studio, il est essentiel que les versions ultérieures de VSPackage conservent la compatibilité descendante avec les versions antérieures de Visual Studio. Lorsque vous ne pouvez pas maintenir la compatibilité descendante, vous devez utiliser des VSPackages privés côte à côte. Pour plus d’informations, consultez Prise en charge de plusieurs versions de Visual Studio.
Ce scénario présente un nouveau programme d’installation VSPackage, tirant parti de la prise en charge de Windows Installer pour les mises à niveau mineures. Les utilisateurs installent simplement la version 1.1 et mettez à niveau la version 1.0. Toutefois, il n’est pas nécessaire d’avoir la version 1.0 sur le système. Le même programme d’installation installe la version 1.1 sur un système sans version 1.0. L’avantage de fournir des mises à niveau mineures de cette façon est qu’il n’est pas nécessaire de passer par le travail de développement d’un programme d’installation de mise à niveau et d’un programme d’installation complet. Un programme d’installation effectue les deux tâches. Un correctif de sécurité ou service pack peut à la place tirer parti des correctifs Windows Installer. Pour plus d’informations, consultez Correctifs et mises à niveau.
Scénario 3 : VSPackage côte à côte
Ce scénario présente deux programmes d’installation VSPackage : un pour chaque version de Visual Studio .NET 2003 et Visual Studio. Chaque programme d’installation installe un VSPackage côte à côte ou privé (qui est spécifiquement créé et installé pour une version particulière de Visual Studio). Chaque VSPackage se trouve dans son propre composant. Par conséquent, chacun peut être pris en service individuellement avec des correctifs ou des versions de maintenance. Étant donné que la DLL VSPackage est désormais spécifique à la version, il est sûr d’inclure ses informations d’inscription dans le même composant que la DLL.
Chaque programme d’installation inclut également du code partagé entre les deux programmes d’installation. Si le code partagé est installé à un emplacement commun, l’installation des deux fichiers .msi n’installe le code partagé qu’une seule fois. Le deuxième programme d’installation incrémente simplement un nombre de références sur le composant. Le nombre de références garantit que si l’un des VSPackages est désinstallé, le code partagé reste pour l’autre VSPackage. Si le deuxième VSPackage est également désinstallé, le code partagé est supprimé.
Scénario 4 : Mise à jour VSPackage côte à côte
Dans ce scénario, votre VSPackage pour Visual Studio a subi une vulnérabilité de sécurité et vous devez émettre une mise à jour. Comme dans le scénario 2, vous pouvez créer un fichier .msi qui met à jour une installation existante pour inclure le correctif de sécurité, ainsi que déployer de nouvelles installations avec le correctif de sécurité déjà en place.
Dans ce cas, VSPackage est un VSPackage géré installé dans le Global Assembly Cache (GAC). Lorsque vous la régénérez pour inclure le correctif de sécurité, vous devez modifier la partie numéro de révision du numéro de version de l’assembly. Les informations d’inscription du nouveau numéro de version d’assembly remplacent la version précédente, ce qui entraîne le chargement de l’assembly fixe par Visual Studio.
Pour plus d’informations sur le déploiement d’assemblys côte à côte, consultez Simplification du déploiement et résolution de DLL Hell with the .NET Framework.