IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bill Fassinou

133PARTAGES

5  0 
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 de continuer à travailler dans l'EDI et de faire le travail en arrière-plan, par exemple, en ajoutant une nouvelle référence.

Comme l'utilisateur peut modifier un projet alors que le système de projet traite des modifications précédentes en arrière-plan, le système de projet doit enregistrer des instantanés des données du projet pour s'assurer qu'une action ultérieure n'entre pas en conflit avec une action précédente. Par conséquent, le système de projet peut facilement se retrouver avec plusieurs copies des données d'un projet en mémoire à la fois. Si le système de projet ne prend pas soin de gérer ces copies, elles peuvent être conservées plus longtemps que nécessaire, voire faire l'objet de fuites et être conservées de manière permanente.

Vick a annoncé que son équipe et lui sont conscients des problèmes que cela peut poser et travaillent donc avec acharnement pour réduire le nombre de copies que le système de projet peut conserver en une fois.

Amélioration de la charge de solution

« Avec tout ce travail, nous avons considérablement optimisé l'expérience de travail avec les grandes solutions .NET 5 et .NET Core », a déclaré Vick. « À partir de la version 16.8, nous avons constaté, dans nombre de nos tests, une amélioration de 2,5 fois de la taille de la solution que nous pouvons ouvrir avant de rencontrer des problèmes de ressources. Nous avons également constaté une diminution allant jusqu'à 25 % des pannes signalées en raison de l'épuisement des ressources », a ajouté l'ingénieur.

Selon lui, les améliorations énumérées ci-dessus ne sont que le début des changements que nous apportons pour améliorer l'expérience de travail avec des solutions de grande taille dans Visual Studio. Toutefois, il note que les performances des solutions individuelles peuvent encore varier, en fonction de la taille de la solution, du type de projets, des extensions chargées, etc. Il invite donc les développeurs qui rencontreront d'autres problèmes à contacter l'équipe pour une assistance.

Source : Microsoft

Et vous ?

Que pensez-vous des optimisations apportées à Visual Studio ?
Avez-vous déjà migré ou entamé la migration de votre projet vers .NET 5 ?
Quels sont les problèmes que vous et votre organisation avez rencontrés lors de la migration ?

Voir aussi

Microsoft a annoncé la disponibilité générale de .NET 5 qui inclut C# 9, F# 5 et une prise en charge native de Windows Arm64

Depuis qu'il a effectué une migration vers .NET 5.0, le développeur de la bibliothèque .NET Fusion a constaté une nette amélioration des performances

Avec .NET 5, Microsoft voudrait produire un environnement d'exécution .NET unique et une infrastructure utilisable partout

.NET 5 : Benchmark.NET est dorénavant l'outil canonique pour mesurer la performance du code .NET. Voici un aperçu des améliorations de performances à venir dans .NET 5

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 06/02/2021 à 22:55
Que pensez-vous des optimisations apportées à Visual Studio ?

Commencer à optimiser, pour une version 16 d'un IDE, j'ai envie de dire "C'est pas trop tôt" .
Venir parler d'optimisations pourtant évidente (ça fait longtemps qu'MS en parle quand même) sur le tooling, juste maintenant, .
Pareille, le coup de Roslyn qui tourne dans l'IDE, ça vient d'où cette idée ?

Avez-vous déjà migré ou entamé la migration de votre projet vers .NET 5 ?

Franchement, la migration n'est envisageable que pour des projets à longue durée de vie, sinon aucun intérêts à passer sur .NET 5 pour d'anciens projets, surtout au vue de la consistance qu'a MS à tout "révolutionner" dans l'écosystème .NET ces derniers temps.

Quels sont les problèmes que vous et votre organisation avez rencontrés lors de la migration ?

Je n'ai pas eu ce désagrément, mais je compati .
1  0 
Avatar de vanquish
Membre expérimenté https://www.developpez.com
Le 08/02/2021 à 9:24
Quand j'ai commencé à travailler sur .Net, c'était déjà la version 16.8

J'adore VS et la productivité qu'il permet en C#
Mais punaise, qu'est-ce que cela devait être en .Net 5 avant la 16.8, car VS est devenu incroyablement mou et lent.

Quand au passage massive de .Net Framework à .Net 5 d'ancien projet, il faudrait que VS est un meilleur support des Winform.
C'est en béta depuis des mois et de maj en maj, on ne voit absolument aucune amélioration (pas même au niveau des notes de versions), à ce demander si c'est toujours dans les projet de MS d'aller au bout de ce support.
Or en l'état l'éditeur visuel est quasi inutilisable.
1  0 
Avatar de kilroyFR
Membre éprouvé https://www.developpez.com
Le 10/02/2021 à 0:33
Que pensez-vous des optimisations apportées à Visual Studio ?
Microsoft poussif encore et toujours, meme sur des machines costauds avec SSD on se demande ce que fait l'application. C'est effectivement devenu un monstre.

Avez-vous déjà migré ou entamé la migration de votre projet vers .NET 5 ?
Migration planifiée mais pas du tout convaincu des nouveautés apportées par .net5 (passer de web.config a appsettings.json, Pattern option de partout, Injection de dependance a gogo de là a supprimer totalement les classes statiques, utilisation des extensions IOC, Logger génériques Microsoft qui font moins que la plupart des ténors existants etc). Je vois des ayatolas qui reecrivent des pans entiers pour appliquer ces différents elements afin de s'affranchir de toutes dépendances non microsoftienne. Je n'adhere pas tant je ne leur fait plus confiance.
Razor/webAssembly ca me semble encore prematuré, la plupart de mes collègues dev dans le digital préfèrent se limiter aux technos web traditionnelles (Framework js/ts etc). Echaudés par SL/WPF plus personne ne suit aveuglement M$ dans ma boite.

J'irai vers cette migration parce que c'est planifié pour dans les prochains mois et j'ai déjà d'ailleurs commencé la migration en tache de fond mais bon les "nouveaux concepts" a la sauce Microsoft j'ai du mal.
L'impression qu'ils passent plus de temps a revoir l'esthetique de leur langage qu'autre chose (faire en 2 lignes de code ce qu'on faisait en 3). Pas vraiment dans le langage que je les attends. Un Framework cross plateforme .net qui tiendrait la route (pour eviter QT par exemple) serait une bonne idee; Oublions les WPF et autres désormais totalement obsolètes.
0  0 
Avatar de kilroyFR
Membre éprouvé https://www.developpez.com
Le 10/02/2021 à 0:38
Citation Envoyé par vanquish Voir le message

Quand au passage massive de .Net Framework à .Net 5 d'ancien projet, il faudrait que VS est un meilleur support des Winform.
C'est en béta depuis des mois et de maj en maj, on ne voit absolument aucune amélioration (pas même au niveau des notes de versions), à ce demander si c'est toujours dans les projet de MS d'aller au bout de ce support.
Or en l'état l'éditeur visuel est quasi inutilisable.
Tout a fait d'accord, la partie client lourde est devenue la 5eme roue du carosse. Rien qui tiet vraiment la route / perenne et la maintenance/evolutions n'en parlons pas, c'est quasi inexistant, y en a plus que pour le web.
0  0