Au début de la semaine dernière, nous avons publié
Visual Studio 2019 v.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'avez pas encore configuré pour recevoir les versions d'aperçu, faites-
le maintenant . La version de prévisualisation est installée sans problème à côté de la version finale, afin qu'ils n'interfèrent pas entre eux. Je recommande fortement à tous les auteurs d'extensions d'installer la version Preview.
Avez-vous actuellement installé 16.1 Preview? Super Voici quelques fonctionnalités qui pourraient vous plaire. Détails sous la coupe!
Support 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 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 existe des changements importants entre les versions que vous souhaitez prendre en charge. Maintenant, il est devenu beaucoup plus facile de diviser l'extension.
Dans Visual Studio 2019 v.16.1 Preview 1, nous avons ajouté la prise en charge des références au projet partagé à 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 le code spécifique pour la version prise en charge de Visual Studio. Le résultat est deux VSIX distincts qui ciblent leur propre gamme de versions de Visual Studio et partagent la plupart du code d'un projet commun. Consultez 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 le fichier .resx marqué avec la propriété
MergeWithCTOMSBuild . Les modèles dans Visual Studio se chargent d'ajouter ce fichier et également d'ajouter le fichier .ico référencé par le fichier .resx. Cependant, le besoin de .resx est un détail d'implémentation, et la plupart des extensions n'ont pas besoin de l'utiliser.
Pour simplifier le projet VSIX, l'exigence de fichier .resx /.ico a été supprimée pour ceux qui utilisent le dernier package NuGet
Microsoft.VSSDK.BuildTools 16.0 ou version ultérieure.
En arrière-plan, le package NuGet fournit un .resx vide pour la compilation avec la propriété MergeWithCTO jusqu'à ce que vous enregistriez le vôtre dans le projet.
Sensibilisation par moniteur
Une prise en charge supplémentaire par moniteur est incluse dans 16.1 avec .NET Framework 4.8 installé. L'interface utilisateur de Windows Forms est désormais meilleure pour 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 mapper le comportement de mise à l'échelle de Visual Studio 2017 en empaquetant la création de votre formulaire ou contrôle dans
DpiAwareness.EnterDpiScope .
using (DpiAwareness.EnterDpiScope(DpiAwarenessContext.SystemAware)) using (var form = new MyForm()) { form.ShowDialog(); }
Tout ce que vous avez à faire est d'ajouter un lien vers le package NuGet
Microsoft.VisualStudio.DpiAwareness . Utilisez ce package dans les extensions ciblant les versions antérieures de Visual Studio, mais gardez à l'esprit qu'il ne fonctionnera que lorsqu'il sera utilisé dans les versions 16.1 et ultérieures. Par conséquent, il peut être utilisé dans des extensions qui s'étendent sur plusieurs versions de Visual Studio.
Pour simplifier la simulation de plusieurs moniteurs fonctionnant avec différentes échelles DPI, l'ingénieur de l'équipe Visual Studio IDE a créé un
petit outil pratique et l'a placé sur GitHub . L'équipe a utilisé cet outil lorsqu'elle a ajouté la prise en charge de la sensibilisation par moniteur, vous pouvez donc également le trouver utile.
En savoir plus sur la façon de travailler avec
Per-Monitor Awareness .
Démarrage synchrone désactivé
Il y a 18 mois, nous avons envoyé un e-mail aux partenaires d'extension, annonçant l'obsolescence du démarrage synchrone des packs d'extension. Il y a un an, nous avons publié
un article de blog contenant des informations plus détaillées sur le fait que le package de démarrage automatique synchrone ne sera plus pris en charge dans une future version de Visual Studio. Cette version est 16.1.
Il existe de bons
exemples de mise à niveau vers
AsyncPackage avec le chargement en arrière-plan activé, et la plupart des extensions d'aujourd'hui ont déjà effectué une transition. Si vous ne l'avez pas déjà fait, il est temps de le faire avant que 16.1 ne quitte le mode d'aperçu.
Nouveau SDK de métapaquet
Le métapaquet
Microsoft.VisualStudio.SDK est un package NuGet distinct qui fait référence à tous les différents packages Visual Studio qui composent le SDK. La chose la plus cool à propos du métapaquet est que vous avez accès à toutes les interfaces et services. En outre, vous évitez également les problèmes liés aux versions incompatibles des packages.
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étapaquet SDK. En effet, la version 16.0 était toujours en cours de développement. Tous les packages individuels devaient être publiés sur NuGet avant que nous puissions obtenir leur dépendance à partir du méta-package.
La bonne nouvelle est que nous sommes enfin prêts pour la version 16.0. Si votre extension prend en charge la version 16.0, vous devez l'utiliser. Vous pouvez également en savoir plus sur les
versions d'extension ici .