Gérer les associations de fichiers côte à côte
Si votre VSPackage fournit des associations de fichiers, vous devez décider comment gérer les installations côte à côte dans lesquelles une version particulière de Visual Studio doit être appelée pour ouvrir un fichier. Les formats de fichiers incompatibles ont composé le problème.
Les utilisateurs s’attendent à ce qu’une nouvelle version d’un produit soit compatible avec les versions antérieures afin que les fichiers existants puissent être chargés dans une nouvelle version sans perdre de données. Dans l’idéal, votre VSPackage peut charger et enregistrer les formats de fichier des versions antérieures. Si ce n’est pas vrai, vous devez proposer de mettre à niveau le format de fichier vers la nouvelle version de votre VSPackage. L’inconvénient de cette approche est que le fichier mis à niveau ne peut pas être ouvert dans la version antérieure.
Pour éviter ce problème, vous pouvez modifier les extensions lorsque les formats de fichier deviennent incompatibles. Par exemple, la version 1 de votre VSPackage peut utiliser l’extension, .mypkg10 et la version 2 peut utiliser l’extension . mypkg20. Cette différence identifie le VSPackage qui ouvre un fichier particulier. Si vous ajoutez des VSPackages plus récents à la liste des programmes associés à une ancienne extension, les utilisateurs peuvent cliquer avec le bouton droit sur le fichier et choisir de l’ouvrir dans un VSPackage plus récent. À ce stade, votre VSPackage peut proposer de mettre à niveau le fichier vers le nouveau format ou d’ouvrir le fichier et de maintenir la compatibilité avec les versions antérieures de VSPackage.
Remarque
Vous pouvez combiner ces approches. Par exemple, vous pouvez offrir une compatibilité descendante en chargeant un fichier plus ancien et en proposant de mettre à niveau le format de fichier lorsque l’utilisateur l’enregistre.
Faire face au problème
Si vous souhaitez que plusieurs VSPackages côte à côte utilisent la même extension, vous devez choisir la version de Visual Studio associée à l’extension. Voici deux alternatives :
Ouvrez le fichier dans la dernière version de Visual Studio installée sur l’ordinateur d’un utilisateur.
Dans cette approche, votre programme d’installation est chargé de déterminer la dernière version de Visual Studio et d’inclure celle-ci dans l’entrée de Registre écrite pour l’association de fichiers. Dans un package Windows Installer, vous pouvez inclure des actions personnalisées pour définir une propriété qui indique la dernière version de Visual Studio.
Remarque
Dans ce contexte, « latest » signifie « dernière version prise en charge ». Ces entrées du programme d’installation ne détectent pas automatiquement une version ultérieure de Visual Studio. Les entrées dans la détection de la configuration système requise et dans les commandes qui doivent être exécutées après l’installation sont similaires à celles présentées ici et sont nécessaires pour prendre en charge des versions supplémentaires de Visual Studio.
Les lignes suivantes de la table CustomAction définissent la propriété DEVENV_EXE_LATEST sur une propriété définie par les tables AppSearch et RegLocator décrites dans Les commandes qui doivent être exécutées après l’installation. Les lignes de la table InstallExecuteSequence planifient les actions personnalisées tôt dans la séquence d’exécution. Les valeurs de la colonne Condition fonctionnent comme suit :
Visual Studio .NET 2002 est la dernière version s’il s’agit de la seule version actuelle.
Visual Studio .NET 2003 est la dernière version uniquement s’il est présent et Visual Studio n’est pas présent.
Visual Studio est la dernière version s’il s’agit de la seule version actuelle.
Le résultat net est que DEVENV_EXE_LATEST contient le chemin d’accès de la dernière version de devenv.exe.
Lignes de table CustomAction qui déterminent la dernière version de Visual Studio
Action Type Source Cible CA_SetDevenvLatest_2002 51 DEVENV_EXE_LATEST [DEVENV_EXE_2002] CA_SetDevenvLatest_2003 51 DEVENV_EXE_LATEST [DEVENV_EXE_2003] CA_SetDevenvLatest_2005 51 DEVENV_EXE_LATEST [DEVENV_EXE_2005] Lignes de table InstallExecuteSequence qui déterminent la dernière version de Visual Studio
Action Condition Séquence CA_SetDevenvLatest_2002 DEVENV_EXE_2002 ET NON (DEVENV_EXE_2003 OU DEVENV_EXE_2005) 410 CA_SetDevenvLatest_2003 DEVENV_EXE_2003 ET NON PAS DEVENV_EXE_2005 420 CA_SetDevenvLatest_2005 DEVENV_EXE_2005 430 Vous pouvez utiliser la propriété DEVENV_EXE_LATEST dans la table registre du package Windows Installer pour écrire la valeur par défaut de la clé ProgIdShellOpenCommand HKEY_CLASSES_ROOT, [DEVENV_EXE_LATEST] « %1 »
Exécutez un programme de lanceur partagé qui peut faire le meilleur choix parmi les versions de VSPackage disponibles.
Les développeurs de Visual Studio ont choisi cette approche pour gérer les exigences complexes des plusieurs formats de solutions et de projets résultant de nombreuses versions de Visual Studio. Dans cette approche, vous inscrivez un programme de lanceur en tant que gestionnaire d’extensions. Le lanceur examine le fichier et détermine la version de Visual Studio et de votre VSPackage qui peut gérer ce fichier particulier. Par exemple, si un utilisateur ouvre un fichier qui a été enregistré pour la dernière fois par une version particulière de votre VSPackage, le lanceur peut démarrer ce VSPackage dans la version correspondante de Visual Studio. En outre, un utilisateur peut configurer le lanceur pour qu’il démarre toujours la dernière version. Un lanceur peut également inviter un utilisateur à mettre à niveau le format du fichier. Si le format du fichier inclut un numéro de version, le lanceur peut informer un utilisateur si le format de fichier provient d’une version ultérieure à une ou plusieurs des VSPackages installés.
Le lanceur doit se trouver dans un composant Windows Installer partagé avec toutes les versions de votre VSPackage. Ce processus garantit que la dernière version est toujours installée et n’est pas supprimée tant que toutes les versions de votre VSPackage ne sont pas désinstallées. De cette façon, les associations de fichiers et d’autres entrées de Registre du composant du lanceur sont conservées même si une version du VSPackage est désinstallée.
Désinstaller et les associations de fichiers
La désinstallation d’un VSPackage qui écrit des entrées de Registre pour les associations de fichiers supprime les associations de fichiers. Par conséquent, l’extension n’a aucun programme associé. Windows Installer ne « récupère » pas les entrées de Registre qui ont été ajoutées lors de l’installation de VSPackage. Voici quelques façons de corriger les associations de fichiers d’un utilisateur :
Utilisez un composant de lanceur partagé comme décrit précédemment.
Demandez à l’utilisateur d’exécuter une réparation de la version de VSPackage que l’utilisateur souhaite posséder l’association de fichiers.
Fournissez un programme exécutable distinct qui réécrit les entrées de Registre appropriées.
Fournissez une page ou une boîte de dialogue d’options de configuration qui permet aux utilisateurs de choisir des associations de fichiers et de récupérer les associations perdues. Demandez aux utilisateurs de l’exécuter après la désinstallation.