Plus tôt cette semaine, nous avons publié Visual Studio 2019 version 16.1 Preview 1 (voir les notes de publication ). Il s'agit du premier aperçu de la première mise à jour de Visual Studio 2019. Si vous n'êtes pas déjà configuré pour obtenir des versions d'aperçu, veuillez le faire maintenant . Le canal de prévisualisation s'installe côte à côte avec le canal de sortie et ils n'interfèrent pas les uns avec les autres. Je recommande fortement à tous les auteurs d'extensions d'installer l'aperçu.
L'aperçu 16.1 est-il installé maintenant? C'est super. Voici quelques fonctionnalités qui pourraient vous intéresser.
Cet article dans le blogSupport de projet partagé
Il existe plusieurs raisons pour lesquelles les auteurs d'extensions doivent parfois diviser une extension en plusieurs projets pour prendre en charge les différentes versions de Visual Studio. Si vous utilisez une API qui n'existait pas pour une version antérieure de Visual Studio ou s'il y a des changements de rupture entre les versions que vous souhaitez prendre en charge, il est maintenant plus simple de fractionner votre extension.
Avec Visual Studio 2019 version 16.1 Preview 1, nous avons ajouté la prise en charge du référencement de projets partagés à partir de projets VSIX dans la même solution.
Vous pouvez placer du code commun dans un projet partagé séparé qui se compile directement dans les projets VSIX au moment de la génération. Le seul code qui existe alors dans les projets VSIX eux-mêmes est un code spécifique à la version de Visual Studio qu'il prend en charge. Le résultat est deux VSIX distincts qui ciblent leur propre plage de versions Visual Studio spécifique et partagent la plupart du code du projet partagé. Extraire le code de l' extension Extension Manager qui fait exactement cela.
Plus besoin de fichier .resx
Lors de l'ajout de commandes, de menus, etc. à l'aide d'un fichier VSCT, vous devez spécifier un fichier .resx marqué avec la propriété MergeWithCTO MSBuild. Les modèles dans Visual Studio se chargent d'ajouter ce fichier et il ajoute également un fichier .ico référencé par le fichier .resx. Cependant, la nécessité d'un .resx est un détail d'implémentation et la plupart des extensions n'ont pas besoin de l'utiliser.
Dans le but de simplifier le projet VSIX, l'exigence relative aux fichiers .resx / .ico a été supprimée lors de l'utilisation de la dernière version 16.0 ou ultérieure du package NuGet Microsoft.VSSDK.BuildTools .
En arrière-plan, le package NuGet fournit un .resx vide à compiler avec la propriété MergeWithCTO , sauf si vous avez enregistré le vôtre dans le projet.
Sensibilisation par moniteur
La prise en charge supplémentaire de la sensibilisation par moniteur est activée dans 16.1 avec .NET Framework 4.8 installé. L'interface utilisateur de Windows Forms gère désormais mieux la mise à l'échelle DPI sur les moniteurs. Cependant, cela peut provoquer des problèmes d'interface utilisateur dans votre extension après l'installation de .NET Framework 4.8.
Lorsque vous utilisez Windows Forms dans une extension, vous pouvez faire correspondre les comportements de mise à l'échelle de Visual Studio 2017 en encapsulant votre formulaire ou en contrôlant la création dans un appel DpiAwareness.EnterDpiScope .
using (DpiAwareness.EnterDpiScope(DpiAwarenessContext.SystemAware)) using (var form = new MyForm()) { form.ShowDialog(); }
Il vous suffit d'ajouter une référence au package NuGet Microsoft.VisualStudio.DpiAwareness . Utilisez ce package dans les extensions ciblant également les versions antérieures de Visual Studio, mais sachez qu'il ne prendra effet que lors de l'exécution en 16.1 et versions ultérieures. Il est donc sûr de l'utiliser dans des extensions couvrant plusieurs versions de Visual Studio.
Pour faciliter la simulation de plusieurs moniteurs fonctionnant avec une mise à l'échelle DPI différente, un ingénieur de l'équipe Visual Studio IDE a créé un petit outil pratique et l'a mis sur GitHub . L'équipe a utilisé cet outil lors de l'ajout de la prise en charge de la sensibilisation par moniteur, vous pouvez donc également le trouver utile.
En savoir plus sur la gestion de la sensibilisation par moniteur pour les extensions .
Chargement automatique synchrone désactivé
Il y a 18 mois, nous avons envoyé un e-mail aux partenaires d'extension annonçant la dépréciation du chargement automatique synchrone des packages d'extension. Il y a un an, nous avons suivi un article de blog avec plus de détails qui décrivait que le package chargé automatiquement de manière synchrone ne serait pas pris en charge dans une future version de Visual Studio. Cette version est 16.1.
Il existe d'excellents exemples sur la façon de migrer vers AsyncPackage avec le chargement en arrière-plan activé, et la plupart des extensions ont déjà effectué la transition. Si vous ne l'avez pas déjà fait, c'est le bon moment pour le faire avant que la 16.1 ne sorte de l'aperçu.
Nouveau méta-package SDK
Le méta-package Microsoft.VisualStudio.SDK est un seul package NuGet qui référence tous les différents packages Visual Studio qui composent le SDK. Ce qui est cool avec le meta package, c'est que vous avez accès à toutes les interfaces et services. En outre, vous évitez également les problèmes liés aux versions de packages incompatibles.
Lorsque nous avons publié Visual Studio 2019 (16.0), le modèle de projet VSIX faisait référence à la version 15.9 du méta package SDK. En effet, la version 16.0 était encore en cours de développement. Tous les packages individuels devaient être publiés sur NuGet avant que nous puissions en dépendre du méta-package.
La bonne nouvelle est que la version 16.0 est enfin prête. Vous devez l'utiliser si la version la plus récente de Visual Studio si votre extension prend en charge 16.0. et vous pouvez en savoir plus sur la gestion des versions des extensions ici .
Gestionnaire de programme principal, extensibilité Visual Studio