Inscription de VSPackage
Les VSPackages doivent indiquer à Visual Studio qu’ils sont installés et doivent être chargés. Ce processus est effectué en écrivant des informations dans le Registre. Il s’agit d’un travail classique d’un programme d’installation.
Remarque
Il s’agit d’une pratique acceptée pendant le développement VSPackage pour utiliser l’inscription automatique. Toutefois, les partenaires du programme VSIP (Visual Studio Industry Partner) ne peuvent pas expédier leurs produits à l’aide de l’autoinscription dans le cadre de la configuration.
Les entrées de Registre dans un package Windows Installer sont généralement effectuées dans la table Registre. Vous pouvez également inscrire des extensions de fichier dans la table Registre. Toutefois, Windows Installer fournit une prise en charge intégrée via l’identificateur programmatique (ProgId), la classe, l’extension et les tables détaillées. Pour plus d’informations, consultez Tables de base de données.
Assurez-vous que vos entrées de Registre sont associées au composant approprié pour votre stratégie côte à côte choisie. Par exemple, les entrées de Registre pour un fichier partagé doivent être associées au composant Windows Installer de ce fichier. De même, les entrées de Registre pour un fichier spécifique à la version doivent être associées au composant de ce fichier. Sinon, l’installation ou la désinstallation de votre VSPackage pour une version de Visual Studio peut interrompre votre VSPackage dans d’autres versions. Pour plus d’informations, consultez Prise en charge de plusieurs versions de Visual Studio.
Remarque
Le moyen le plus simple de gérer l’inscription consiste à utiliser les mêmes données dans les mêmes fichiers pour l’inscription des développeurs et l’inscription au moment de l’installation. Par exemple, certains outils de développement d’installation peuvent consommer un fichier au format .reg au moment de la génération. Si les développeurs gèrent des fichiers .reg pour leur propre développement et débogage quotidiens, ces mêmes fichiers peuvent être inclus automatiquement dans le programme d’installation. Si vous ne pouvez pas partager automatiquement les données d’inscription, vous devez vous assurer que la copie du programme d’installation des données d’inscription est active.
Inscription de VSPackages non managés
Les VSPackages non managés (y compris ceux générés par le modèle de package Visual Studio) utilisent des fichiers .rgs de style ATL pour stocker les informations d’inscription. Le format de fichier .rgs est spécifique à ATL et ne peut généralement pas être consommé tel quel par un outil de création d’installation. Les informations d’inscription pour le programme d’installation de VSPackage doivent être conservées séparément. Par exemple, les développeurs peuvent conserver les fichiers au format .reg synchronisés avec les modifications de fichier .rgs. Les fichiers .reg peuvent être fusionnés avec RegEdit pour le travail de développement ou consommés par un programme d’installation.
Inscription de VSPackages managés
L’outil RegPkg lit les attributs d’inscription à partir d’un VSPackage managé et peut écrire les informations directement dans le Registre ou écrire des fichiers au format .reg qui peuvent être consommés par un programme d’installation.
Remarque
L’outil RegPkg n’est pas redistribuable et ne peut pas être utilisé pour inscrire un VSPackage sur le système d’un utilisateur.
Pourquoi les VSPackages ne doivent pas s’inscrire automatiquement au moment de l’installation
Vos programmes d’installation VSPackage ne doivent pas s’appuyer sur l’inscription automatique. À première vue, la conservation des valeurs de Registre d’un VSPackage uniquement dans le VSPackage lui-même semble être une bonne idée. Étant donné que les développeurs ont besoin des valeurs de Registre disponibles pour leur travail de routine et leur test, il est judicieux d’éviter de conserver une copie distincte des données du Registre dans le programme d’installation. Le programme d’installation peut s’appuyer sur le VSPackage lui-même pour écrire des valeurs de Registre.
Bien que bon en théorie, l’autoinscription a plusieurs défauts qui le rendent inadapté à l’installation de VSPackage :
La prise en charge correcte de l’installation, de la désinstallation, de la restauration de l’installation et de la restauration de désinstallation vous oblige à créer quatre actions personnalisées pour chaque VSPackage managé qui s’inscrit automatiquement en appelant RegPkg.
Votre approche de la prise en charge côte à côte peut nécessiter la création de quatre actions personnalisées qui appellent RegSvr32 ou RegPkg pour chaque version prise en charge de Visual Studio.
Une installation avec des modules auto-inscrits ne peut pas être restaurée en toute sécurité, car il n’existe aucun moyen de dire si les clés auto-inscrites sont utilisées par une autre fonctionnalité ou application.
Les DLL auto-inscrites sont parfois liées à des DLL auxiliaires qui ne sont pas présentes ou qui sont incorrectes. En revanche, Windows Installer peut inscrire des DLL à l’aide des tables de Registre sans dépendance sur l’état actuel du système.
Le code d’inscription automatique peut être refusé à des ressources réseau, telles que des bibliothèques de types, si un composant est à la fois spécifié comme run-from-source et est répertorié dans la table SelfReg. Cela peut entraîner l’échec de l’installation du composant lors d’une installation administrative.