Sorti le 8 novembre 2021, Visual Studio 2022 n’a jusqu’à présent guère réjoui de nombreux développeurs. En effet, le passage à une application 64 bits a souvent entraîné des plantages de l’éditeur et de la fonction Hot Reload, tant vantée par Microsoft lors de son lancement.

L’entreprise promet maintenant, avec la première mise à jour sous le numéro de version 17.1, une plus grande stabilité et un meilleur fonctionnement de Hot Reload en combinaison avec les applications Blazor. Lors d’un premier test rapide effectué le 16 février, le rechargement à chaud d’une application Blazor WebAssembly a effectivement fonctionné de manière plus fiable que dans la version 17.0, selon l’auteur de ce message.

Recherche rapide et sauvegarde automatique

Parmi les points forts de la mise à jour des fonctionnalités, on trouve la recherche plein texte fortement accélérée dans les fichiers. Pour cela, l’IDE lance désormais automatiquement un autre processus appelé ServiceHub.IndexingService.exe. Les utilisateurs peuvent toutefois désactiver ce service dans les paramètres de l’IDE en cas de problème.

Sous Settings/Environment/Documents les développeurs peuvent désormais trouver un nouveau paramètre qui permet à Visual Studio d’enregistrer automatiquement les fichiers modifiés lorsque l’IDE perd le focus. Lors d’un test rapide dans une application Blazor, les fichiers modifiés étaient certes enregistrés lorsque l’on passait de l’éditeur à la fenêtre du navigateur en cliquant dessus, mais la fonction Hot Reload activée ne le remarquait pas ; le contenu du navigateur n’était actualisé qu’après un enregistrement explicite.

Une autre nouveauté est que l’IDE peut appliquer automatiquement les fonctions de nettoyage du code introduites dans Visual Studio 2019 à chaque enregistrement, si les développeurs le souhaitent. L’interface utilisateur graphique pour les Editor Config Files, également disponible depuis la version 2019, propose désormais, en plus de « Whitespace », « Code Style » et « Analyzers », un onglet pour « Naming Style ».

Refactoring et sauts dans le code source de NuGet

Les développeurs peuvent désormais étendre d’un simple clic les filtres de solution (fichiers .slnf) introduits dans Visual Studio 2019 aux projets ajoutés ultérieurement. Il est possible de choisir individuellement les couleurs souhaitées pour les onglets pouvant être colorés par projet ou par type de fichier.

L’éditeur C# de la version 17.1 offre également de nouvelles fonctions de refactoring : Les membres statiques peuvent être déplacés vers d’autres types, l’échange de valeurs entre deux variables peut être effectué par un tuple au lieu d’une variable temporaire, la syntaxe des propriétés étendues peut être appliquée à la syntaxe imbriquée avec la notation par points de C# 10 et la directive #nullable enable du code vers le fichier de projet. La fonction Aller à la définition affiche désormais le code source des assemblages issus de paquets NuGet, si ces derniers soit incluent le code source, soit le fournissent par lien source.

Avertissements et erreurs au premier coup d’œil

Encore expérimental et à activer explicitement dans les paramètres de l’IDE, l’affichage des avertissements et des erreurs directement dans l’éditeur au lieu de l’info-bulle. Un message de heise Developer montre que tous les avertissements, comme par exemple l’absence d’une interface utilisateur, n’ont pas encore été pris en compte. await dans la figure 1 – apparaissent sous cette forme.

Les Data-Tipps, qui existent depuis de nombreuses années dans le Debugger et qui montrent la valeur actuelle des variables, peuvent maintenant être configurés de manière à ce qu’ils ne se ferment plus au déplacement de la souris, mais seulement après un clic.

La fenêtre « Stack Trace Explorer » est une toute nouvelle fonctionnalité de Visual Studio 2022 version 17.1 : Les développeurs peuvent y copier le texte d’une pile d’appels et ensuite aborder les méthodes de la chaîne d’appels dans l’éditeur. Cela est utile si l’on ne dispose pas de la pile d’appels à partir de l’opération actuelle du débogueur, mais d’un débogage antérieur ou d’un fichier journal. Toutefois, lors d’un premier test, le Stack Trace Explorer fonctionne encore de manière assez maladroite.

Plus de confort avec Git

Depuis un certain temps déjà, Microsoft travaille à l’amélioration des interfaces graphiques pour l’utilisation de la gestion du code source Git au sein de Visual Studio. Dans la version 17.1, les utilisateurs de Visual Studio peuvent désormais comparer graphiquement les branches Git entre elles. Pour ce faire, il suffit de sélectionner dans le menu Git/Manage Branches la branche qui doit être comparée à celle qui est actuellement ouverte (voir fig. 2).

Dans la même fenêtre, un clic sur un commit permet d’ouvrir l’état du dépôt à ce moment-là (correspond à un git checkout –detach). Microsoft a également amélioré la prise en charge du travail simultané avec plusieurs référentiels : en une seule action, il est possible de créer une branche dans tous les référentiels impliqués dans la solution de projet actuelle.

Avec « Line Staging », les développeurs peuvent composer un commit à partir des modifications apportées à des lignes individuelles. Le test rapide montre cependant que Visual Studio ne sépare pas toujours clairement les lignes de code. Comme le montre la figure 3, la modification pour l’ajout du commentaire XML (lignes 21 à 23) et la modification du nom de paramètre (ligne 24) peuvent être archivées séparément. Cette fonctionnalité, tout comme la prise en charge de plusieurs référentiels Git dans une solution, est encore au stade de l’aperçu dans la version finale 17.1 et doit être activée à l’adresse suivante Settings/Environment/Preview Features doit être activé par l’utilisateur.

Nouvelles fonctionnalités non disponibles dans le LTSC

Il convient de noter que les utilisateurs de Visual Studio Professional et Visual Studio Enterprise ne se voient proposer les nouvelles fonctionnalités mentionnées dans cet article que s’ils sont sur le canal « Current » ou « Preview ». Les clients qui ont réglé Visual Studio sur « Long Term Support Channel » (LTSC) dans les paramètres de mise à jour recevront certes des corrections de bugs via des mises à jour par des mises à jour mineures (17.0.x), mais pas de nouvelles fonctionnalités. Seule la version 17.2 sera à nouveau une version LTSC, que Microsoft servira alors à chaque fois pendant 18 mois avec des corrections de bugs (voir illustration 4).

Après la release, avant la preview

Parallèlement à la version finale de Visual Studio 2022 version 17.1, une première version preview de la version 17.2 est déjà sortie.

Dans cette version, l’éditeur Razor prend enfin en charge les Code Snippets qui font souvent défaut. De plus, Microsoft fournit ici le support pour la première version de prévisualisation pour .NET 7 et C# 11 – les deux paquets d’installation devraient être disponibles dans la semaine à venir.

.NET MAUI, la 13e version du logiciel de développement de logiciels.

La version 17.2 Preview 1 est nécessaire si l’on veut utiliser la treizième version d’aperçu de .NET Multi-Platform App UI (.NET MAUI), également publiée le 15 février. Microsoft y a une nouvelle fois remanié le modèle d’application. Au lieu de la bibliothèque Microsoft.Extensions.Hosting utilisée dans les applications Web basées sur .NET, il y a maintenant des classes de démarrage d’application spécifiques par plate-forme (Android, iOS, macOS, Windows), qui peuvent ensuite créer une classe de démarrage multi-plateforme (nom par défaut : MauiProgram), dans laquelle les éléments d’interface utilisateur et les bibliothèques peuvent être configurés. Ce nouveau mécanisme devrait permettre d’accélérer le lancement des applications de 13 %, en particulier sur Android.

.NET MAUI devait initialement être lancé avec .NET 6 en novembre, mais a été reporté au deuxième trimestre 2022.