Microsoft annonce qu'il a apporté quelques améliorations importantes à Visual Studio 2019 16.8

Afin de faciliter la migration de projets d'envergure de .NET Framework vers .NET 5

Environ 4 mois après la publication de .NET 5, Microsoft a annoncé jeudi dans un billet de blogue qu'il a constaté que les développeurs et les entreprises sont nombreux à migrer vers la première version de sa plateforme unifiée .NET 5. Cette vague de migration concernerait essentiellement de grandes solutions écrites avec .NET Framework. Pour faciliter la tâche aux développeurs, Microsoft a annoncé qu'il a optimisé l'EDI Visual Studio 2019 16.8 sur cinq différents points pour qu'il puisse traiter des solutions contenant un grand nombre de projets .NET 5 et .NET Core. Voici ci-dessous un aperçu des différentes mises à jour.

.NET 5 : une unification des différents outils de la plateforme .NET

Microsoft annonçait en 2019 l'arrivée de .NET 5, qui, selon l'entreprise, sera son premier grand produit sur la voie de l'unification de la plateforme .NET. Après près de deux ans de développement, Microsoft a publié .NET 5 en novembre dernier. .NET 5 représente la première version de cet effort d'unification des différentes variantes de .NET à travers les systèmes d'exploitation, le Web et une variété de facteurs de forme. .NET 5 succède ainsi à .NET Core 3.X. Microsoft a rassuré que le .NET Framework existant reste un produit qu'il continuera de mettre à jour avec chaque nouvelle version de Windows.


Rappelons qu'en 2020, il a cessé d'ajouter de nouvelles fonctionnalités à .NET Framework à partir de la version 4.8 et a aussi fini d'ajouter les API du .NET Framework au .NET Core. Il ne prévoit pas non plus de publier une nouvelle version de .NET Standard. L'entreprise a annoncé la fin de .NET Standard pendant l'été 2020, mais elle a aussi précisé que .NET 5 et toutes les versions futures continueront à prendre en charge le .NET Standard 2.1 et les versions antérieures. .NET 5 fournit aux développeurs des outils, des interfaces de programmation, des fonctionnalités d'exécution et de nouveaux langages.

C'est ce que Microsoft préconise aux développeurs d'utiliser pour créer des interfaces utilisateur Web et des services de backend. « Nous avions l'intention de réaliser l'intégralité de la vision d'unification avec .NET 5.0, mais dans le sillage de la pandémie mondiale, nous avons dû nous adapter à l'évolution des besoins de nos clients », ont déclaré les responsables dans le billet de blogue annonçant la sortie de .NET 5. Les développeurs semblent avoir suivi les recommandations de l'entreprise, car elle a annoncé jeudi que beaucoup d'entre eux migrent déjà vers .NET 5. Elle veut donc faciliter cela à travers une optimisation de Visual Studio.

Exécution du compilateur C# et VB en dehors du processus

Selon Paul Vick, ingénieur logiciel principal de l'équipe de développement de Visual Studio, Roslyn, le compilateur C# et Visual Basic, analyse la solution complète pour alimenter des services tels qu'IntelliSense, "Go to Definition", et les diagnostics/erreurs. Ainsi, Roslyn a tendance à consommer des ressources qui augmentent proportionnellement à la taille de la solution ouverte, ce qui peut devenir assez important pour les grandes solutions. Il estime qu'un travail a déjà été fait sur Roslyn pour minimiser cet impact en mettant en cache de manière agressive sur le disque des informations qui ne sont pas immédiatement nécessaires.

Cependant, même avec cette mise en cache, elle ne peut pas échapper à la nécessité de conserver les données en mémoire. De ce fait, Vick a déclaré qu'afin de réduire son impact sur les solutions Visual Studio de plus grande envergure, l'équipe Roslyn a déployé des efforts considérables pour sortir le compilateur Roslyn du processus Visual Studio et l'intégrer à son propre processus. L'utilisation de Roslyn dans son propre processus libère des ressources au sein de Visual Studio lui-même et permet au compilateur Roslyn d'avoir plus de place pour faire son travail.

D'après ce qu'il dit, pour les solutions de grande taille, cela peut permettre d'économiser jusqu'à un tiers de la mémoire consommée par Visual Studio lorsque vous ouvrez une solution de grande taille.

Rationalisation du nœud Dependencies

La deuxième optimisation apportée par l'équipe à Visual Studio consiste en la rationalisation du nœud "Dependencies" (Dependencies node). En effet, Vick a expliqué que chaque projet .NET 5 et .NET Core possède un nœud dans l'explorateur de solutions appelé "Dépendances" qui affiche toutes les choses dont le projet dépend : autres projets, assemblages, paquets NuGet, etc. En plus de montrer les dépendances immédiates du projet, le nœud montre également les dépendances transitives du projet, c'est-à-dire toutes les choses dont chaque dépendance dépend, etc.

D'après l'ingénieur, l'inconvénient qui en résulte est qu'avec un projet de toute taille raisonnable, cette liste de dépendances transitives peut devenir assez grande. Mais ce n'est pas tout, Vick note également un deuxième inconvénient à la manière dont ce noeud fonctionne. Il estime que la mise en œuvre initiale du nœud "Dépendances" n'était pas particulièrement efficace dans la manière dont elle stockait les informations sur les dépendances transitives en mémoire. Elle conservait beaucoup plus d'informations que nécessaire et la plupart des données étaient redondantes.

Ainsi, pour corriger le tir, l'équipe de développement de l'EDI a réécrit le code pour ne conserver que les informations absolument nécessaires, et a commencé à utiliser les informations existantes sur les dépendances déjà conservées par NuGet. Le porte-parole de l'équipe a annoncé que cette réécriture permet d'économiser jusqu'à 10-15 % de la mémoire consommée par Visual Studio lorsque vous ouvrez une solution de grande envergure.

Réduire les doublons dans MSBuild

Selon Vick, Visual Studio s'appuie sur plusieurs outils qui s'avèrent être voraces en mémoire. Outre, Roslyn, il a déclaré que l'un des autres grands consommateurs de ressources dans un processus de studio visuel est MSBuild. En effet, en tant que moteur de construction, une grande partie de l'expérience de l'IDE est alimentée par le modèle objet de MSBuild. Pour résoudre ce problème, l'équipe a rendu les fichiers de projet eux-mêmes beaucoup plus petits dans .NET 5 et .NET Core. Cela dit, il existe un nombre important de fichiers de projet qui sont importés dans les projets via le SDK.


Vick a déclaré que l'évaluation de tous ces fichiers est nécessaire pour comprendre et construire un projet, et peut consommer jusqu'à un autre tiers de la mémoire consommée par Visual Studio lorsque vous ouvrez une grande solution. Il continue en disant que, bien que les fichiers de projet génèrent beaucoup de données, une grande partie de ces données sont répétitives et l'équipe a choisi de les dupliquer en mémoire. Les chaînes de caractères sont l'un des sous-produits les plus courants du système de projet, et elles stockent des informations comme les noms de fichiers, les options et les chemins d'accès.

Les chemins, en particulier, peuvent être assez longs et peuvent finir par consommer beaucoup de mémoire s'ils sont trop nombreux ou s'ils sont dupliqués trop souvent. En veillant à ne conserver qu'une seule copie d'une chaîne, il est possible d'économiser de 5 à 10 % de la mémoire consommée par Visual Studio lorsqu'on ouvre une grande solution.

Réduire les copies de projet conservées par le système de projet

Vick a expliqué que l'un des aspects importants de la conception du système de projet .NET 5 et .NET Core est l'asynchronie (asynchrony). Souvent, le système de projet doit effectuer un travail en réponse à une action de l'utilisateur (par exemple, ajouter une nouvelle référence à un projet). Au lieu de bloquer Visual Studio pendant qu'il termine son travail, le système de projet permet à l'utilisateur...