Changements cassants de l’API dans Visual Studio 2022
Si vous migrez une extension vers Visual Studio 2022, les modifications cassants répertoriées ici peuvent vous affecter.
Assemblys de référence non installés
Bon nombre des assemblys que vous avez peut-être référencés à partir d’un répertoire d’installation de Visual Studio ne sont plus installés. Vous devez utiliser NuGet pour acquérir les assemblys de référence du Kit de développement logiciel (SDK) Visual Studio dont vous avez besoin. Consultez Moderniser les projets pour obtenir des instructions détaillées sur cette opération.
API supprimées
Dans Visual Studio 2022, un certain nombre d’API ont été supprimées dans le cadre du déplacement de Visual Studio à l’avenir. Vous trouverez la liste des API supprimées dans la page Liste des API supprimées.
Changements cassants d’interopérabilité
La plupart de nos API ont changé dans Visual Studio 2022, généralement avec des modifications simples qui sont simples pour votre code à prendre en charge.
Pour gérer les changements cassants, nous prévoyons de fournir un nouveau mécanisme pour la distribution d’assemblys d’interopérabilité. Plus précisément, pour Visual Studio 2022 et au-delà, nous fournissons un assembly d’interopérabilité unique avec des définitions pour de nombreuses interfaces Visual Studio publiques courantes. Cet assembly contient des définitions managées pour de nombreuses interfaces Visual Studio qui s’éloignent de plusieurs assemblys d’interopérabilité. Le nouvel assembly d’interopérabilité est distribué via le Microsoft.VisualStudio.Interop package NuGet.
Toutefois, les composants Visual Studio qui sont principalement utilisés dans des contextes natifs et qui ont un faible nombre de modifications cassants continueront d’avoir leurs propres assemblys d’interopérabilité (par exemple, l’assembly du débogueur sera toujours VisualStudio.Debugger.Interop.dll comme il le fait aujourd’hui). Dans tous les cas, les assemblys peuvent ensuite être référencés à partir de votre application, tout comme ils le sont aujourd’hui.
Il s’agit d’une modification significative et signifie que les extensions qui utilisent des API dans et un assembly intégrés dans cette nouvelle approche ne sont pas compatibles avec les versions antérieures de Visual Studio à l’aide de l’assembly d’interopérabilité précédent.
Cela présente quelques avantages très importants qui facilitent la mise à jour de votre extension vers Visual Studio 2022 :
- Toutes les API rompues deviennent des erreurs de temps de génération qui facilitent leur recherche et leur correction.
- Vous devez uniquement mettre à jour le code qui utilise une API qui a été interrompue dans Visual Studio 2022.
- Vous ne pourrez pas utiliser accidentellement l’ancienne API rompue.
Dans l’ensemble, ces modifications entraînent une version plus stable de Visual Studio pour tous les utilisateurs. L’inconvénient majeur de cette approche est que vos assemblys managés ne pourront pas s’exécuter dans Visual Studio 2019 et Visual Studio 2022 sans compiler votre code une seule fois pour chaque version de Visual Studio cible.
Lorsque vous effectuez des erreurs de compilation en raison des différences d’API entre Visual Studio 2019 et Visual Studio 2022, vous pouvez trouver l’API ou le modèle répertorié ci-dessous avec des conseils sur la façon de le corriger.
int ou uint où IntPtr est attendu
Nous nous attendons à ce qu’il s’agit d’une erreur très courante. Pour que Visual Studio 2022 soit un processus 64 bits, certaines de nos API d’interopérabilité devaient être corrigées lorsqu’elles supposaient qu’un pointeur pouvait tenir dans un entier 32 bits pour utiliser réellement une valeur de taille de pointeur.
Exemple de l’erreur :
Argument 3 : impossible de convertir « out uint » en « out System.IntPtr »
Il vous suffit de mettre à jour votre code pour s’attendre à ce qu’il s’attende ou UIntPtr indique IntPtr où int ou uint utilisé pour résoudre l’arrêt.
Exemple de correctif :
-shell.LoadLibrary(myGuid, myFlags, out uint ptrLib);
+shell.LoadLibrary(myGuid, myFlags, out IntPtr ptrLib);
Type d’interopérabilité défini dans deux assemblys
Lorsque le compilateur C# signale une erreur indiquant qu’un type que vous utilisez est défini dans deux assemblys, vous référencez probablement un assembly à partir de la version visual Studio 2019 du Kit de développement logiciel (SDK) que vous ne devez plus référencer.
Exemple de l’erreur :
erreur CS0433 : Le type « IVsDpiAware » existe dans « Microsoft.VisualStudio.Interop », Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' et 'Microsoft.VisualStudio.Shell.Interop.16.0.DesignTime, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
Reportez-vous à notre table de remapping d’assembly de référence pour voir quel nom d’assembly est le nom préféré dans Visual Studio 2022.
En considérant les deux assemblys nommés dans l’exemple d’erreur ci-dessus et en examinant cette table, notez qu’il s’agit Microsoft.VisualStudio.Interop du nouveau nom de l’assembly. Le correctif consiste alors à supprimer la référence au Microsoft.VisualStudio.Shell.Interop.16.0.DesignTime projet.
Dans certains cas, nous proposons un package visual Studio 2022 versionné pour l’assembly déprécié qui contient des redirecteurs de type. Lorsque cela est disponible, vous avez la possibilité de mettre à niveau votre référence de package vers la version de Visual Studio 2022 au lieu de la supprimer. Les redirecteurs de type résolvent l’erreur du compilateur.
Gardez à l’esprit que parfois ces références peuvent provenir de références de package transitives et peuvent donc être plus difficiles à supprimer qu’une référence directe faite dans votre fichier projet. Dans ce cas, assurez-vous que toutes vos références directes de package utilisent tous les packages sdk Visual Studio 2022 eux-mêmes. Vous pouvez faire référence à project.assets.json pour identifier la chaîne de packages responsable de l’apport de l’assembly déprécié. La mise à jour d’une référence de package transitive vers une version de Visual Studio 2022 est aussi simple que son installation comme référence directe.
Si vous ne pouvez pas modifier l’arborescence des dépendances (par exemple, car elle implique une dépendance tierce), vous pouvez ajouter une référence de package directe au package pré-Visual Studio 2022 et ajouter ExcludeAssets="compile" des métadonnées à cet PackageReference élément pour résoudre l’erreur du compilateur. Mais gardez à l’esprit qu’avec cette technique, votre extension peut conserver une dépendance sur un assembly pré-Visual Studio 2022 et votre extension peut fonctionner correctement au moment de l’exécution.
Référence manquante à un assembly d’interopérabilité
Lorsque vous référencez un assembly compilé sur le kit SDK pré-Visual Studio 2022, vous risquez d’obtenir une erreur concernant l’absence d’une référence d’assembly.
Exemple de l’erreur :
Erreur CS0012 Le type « IVsTextViewFilter » est défini dans un assembly qui n’est pas référencé. Vous devez ajouter une référence à l’assembly « Microsoft.VisualStudio.TextManager.Interop, Version=7.1.40304.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
À l’aide de la table de remapping d’assembly de référence, vous pouvez confirmer que l’assembly demandé n’est en fait pas celui que vous devez avoir à référencer.
Le meilleur correctif consiste à mettre à jour votre dépendance vers une version compilée par rapport au Kit de développement logiciel (SDK) Visual Studio 2022 afin que l’assembly d’interopérabilité supprimé ne soit plus demandé par le compilateur.
Dans certains cas, nous proposons un package visual Studio 2022 versionné pour l’assembly déprécié qui contient des redirecteurs de type. Lorsque cela est disponible, vous avez la possibilité d’ajouter une référence de package à la version de Visual Studio 2022 du package obsolète afin que les redirecteurs de type résolvent l’erreur du compilateur.
IAsyncServiceProvider est manquant
Il existe deux définitions de cette interface, dans deux espaces de noms. Une seule d’entre elles était destinée à une consommation gérée.
| Espace de noms Visual Studio 2019 | Espace de noms Visual Studio 2022 | Utilisation prévue |
|---|---|---|
| Microsoft.VisualStudio.Shell.IAsyncServiceProvider | Microsoft.VisualStudio.Shell.IAsyncServiceProvider | Consommation de code managé |
| Microsoft.VisualStudio.Shell.Interop.IAsyncServiceProvider | Microsoft.VisualStudio.Shell.COMAsyncServiceProvider.IAsyncServiceProvider | Interopérabilité de bas niveau uniquement |
Si vous voyez une erreur sur IAsyncServiceProvider, il se peut que vous utilisiez celui destiné au code natif (la deuxième ligne).
Si c’est le cas, vous pouvez effectuer une mise à jour vers le nouvel espace de noms ou basculer vers l’interface plus conviviale.
DTE et _DTE échecs de cast de type
DTE et _DTE sont les deux interfaces. L’un dérive de l’autre. Toutefois, dans Visual Studio 2022, les types de base et dérivés sont échangés.
Cela rend certaines affectations de type ou casts qui échouent.
Cela signifie également où vous avez utilisé new DTE(), vous devez maintenant utiliser new _DTE().
Pour atténuer la plupart des problèmes liés à ce problème, utilisez plutôt l’espace DTE2 EnvDTE80 de noms.
Argument manquant sur un appel de méthode
Quelques méthodes ne déclarent plus les arguments par défaut pour les paramètres facultatifs dans l’API d’interopérabilité. Si vous obtenez une erreur concernant un argument manquant pour un appel COM Interop et que les appels de paramètres pour un object type, la valeur par défaut précédente définie par l’API d’interopérabilité Visual Studio 2019 peut avoir été "", donc envisagez d’ajouter "" comme argument pour résoudre l’erreur de compilation.
En cas de doute sur l’argument par défaut utilisé, essayez de basculer votre contexte de service de langage de Visual Studio 2022 vers Visual Studio 2019 afin d’obtenir IntelliSense avec les assemblys d’interopérabilité plus anciens pour voir quel était l’argument par défaut, puis l’ajouter explicitement à votre code. Elle continuera de fonctionner correctement lors de la compilation pour Visual Studio 2019, mais elle sera maintenant compilée pour Visual Studio 2022.
Exemple de correctif :
-process4.Attach2();
+process4.Attach2("");
Dépréciation de l’API De recherche héritée
Dans le cadre de nos efforts de modernisation des fichiers, nous avons déconseillé la prise en charge des API suivantes de l’interface EnvDTE dans VS 2022.
- EditPoint.FindPattern(String, Int32, EditPoint, TextRanges)
- EditPoint.ReplacePattern(TextPoint, String, String, Int32, TextRanges)
- EditPoint.ReplaceText(Object, String, Int32)
- TextSelection.FindText(String, Int32)
- TextSelection.FindPattern(String, Int32, TextRanges)
- TextSelection.ReplaceText(String, String, Int32)
- TextSelection.ReplacePattern(String, String, Int32, TextRanges)
- TextDocument.ReplacePattern(String, String, Int32, TextRanges)
- TextDocument.ReplaceText(String, String, Int32)
Ces API ne fonctionneront plus dans VS 2022 et au-delà. Les conseils sont d’utiliser iFinder Interface (Microsoft.VisualStudio.Text.Operations) à la place, qui a des méthodes de recherche et de remplacement sur celle-ci. L’accès à un objet implémentant l’interface IFinder peut être obtenu via la méthode IFindService.CreateFinderFactory. Vous trouverez un exemple de migration d’une extension tierce vers Visual Studio à partir des anciennes API vers les API IFinder modernes : Migrer l’extension Code Maid d’EnvDTE Find and Replace pattern API to modern IFinder API