La semaine dernière, .NET Core 3.0 (Preview 6) est sorti . Il comprend des mises à jour de compilation d'assembly pour améliorer le lancement, améliorer l'optimisation de la taille de l'application avec des améliorations de l'éditeur de liens et EventPipe. Nous avons également publié de nouvelles images Docker pour Alpine sur ARM64.
Mises à jour WPF et Windows Forms
L'équipe WPF a complètement terminé de publier la plupart du code WPF sur GitHub . En fait, ils viennent de publier le code source de quinze versions . Pour ceux qui connaissent WPF, les noms d'assembly doivent être très familiers.
Dans certains cas, les tests sont toujours dans le backlog et doivent être publiés dans ou avant 3.0 GA. Cependant, la présence de tout ce code devrait permettre à la communauté WPF de participer pleinement à la modification de WPF. Après avoir lu certains problèmes avec GitHub, il devient évident que la communauté a son propre backlog de nouveaux produits que vous souhaitez implémenter. Que pensez-vous du sujet sombre?
Images Alpine Docker
Les images Docker sont désormais disponibles pour .NET Core et ASP.NET Core sur ARM64. Auparavant, ils n'étaient disponibles que pour x64.
Les images suivantes peuvent être utilisées dans le Dockerfile , ou avec le docker pull , comme illustré ci-dessous:
docker pull mcr.microsoft.com/dotnet/core/runtime:3.0-alpine-arm64v8docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0-alpine-arm64v8
Améliorations apportées aux canaux d'événements
Event Pipe prend désormais en charge la multisessionnalité.
Nouveaux compteurs de performances ajoutés:
- % Temps en GC
- Taille de tas Gen 0
- Taille de tas de génération 1
- Taille de tas Gen 2
- Taille du tas LOH
- Taux d'allocation
- Nombre d'ensembles chargés
- Nombre de threads ThreadPool
- Surveiller le taux de conflit de verrouillage
- File d'attente des éléments de travail ThreadPool
- Taux d'éléments de travail terminés ThreadPool
Les jointures de profileur sont désormais implémentées à l'aide de la même infrastructure Event Pipe.
Lisez le jeu de comptage de David Fowler pour avoir une idée de ce que vous pouvez faire avec le tuyau d'événement pour effectuer vos propres recherches de performances ou simplement suivre l'état de l'application.
Lisez dotnet-counters pour installer l'outil dotnet-counters.
Optimisez vos applications .NET Core avec les images ReadyToRun
Vous pouvez améliorer le temps de démarrage d'une application .NET Core en compilant les versions d'application au format ReadyToRun (R2R). R2R est une forme de compilation de premier plan (AOT).
Les binaires R2R améliorent les performances de démarrage en réduisant la quantité de travail que JIT doit faire lors du chargement de l'application. Les binaires contiennent un code machine similaire à celui généré par le JIT, ce qui donne du repos au JIT lorsque les performances sont les plus importantes (au démarrage). Les fichiers binaires au format R2R sont plus volumineux car ils contiennent à la fois du code de langage intermédiaire (IL), qui est toujours nécessaire pour certains scénarios, et une version machine du même code pour améliorer le démarrage.
R2R est pris en charge par .NET Core 3.0. Il ne peut pas être utilisé avec des versions antérieures de .NET Core.
Exemples de chiffres de performance
Les figures suivantes présentent les performances des exemples d'applications WPF . L'application a été publiée en tant que version autonome et n'a pas utilisé l'éditeur de liens d'assembly (abordé plus loin dans cet article).
Application IL uniquement:
- Temps de démarrage: 1,9 secondes
- Utilisation de la mémoire: 69,1 Mo
- Taille de l'application: 150 Mo
Avec les images ReadyToRun:
- Temps de démarrage: 1,3 seconde.
- Utilisation de la mémoire: 55,7 Mo
- Taille de l'application: 156 Mo
En savoir plus sur les images ReadyToRun
Vous pouvez compiler R2R à la fois des bibliothèques et des fichiers binaires d'application. Actuellement, les bibliothèques ne peuvent être compilées dans R2R que dans le cadre de l'application, et non pour être livrées en tant que package NuGet. Nous aimerions avoir plus de commentaires sur l'importance de ce scénario.
La compilation des assemblages AOT est depuis longtemps disponible en tant que concept pour .NET, revenant au .NET Framework et NGEN . Un inconvénient majeur de NGEN est que la compilation doit être effectuée sur les machines clientes à l'aide de l'outil NGEN. Il n'est pas possible de générer des images NGEN dans le cadre de la création de votre application.
Maintenant .NET Core. Il est livré avec crossgen , qui produit des images de machine au nouveau format ReadyToRun . Le nom décrit sa valeur fondamentale, à savoir que ces images de machine peuvent être créées dans le cadre de votre assemblage et sont «prêtes à fonctionner» sans aucun travail supplémentaire sur les machines clientes. Il s'agit d'une amélioration majeure, ainsi que d'une victoire importante dans la lutte contre le changement climatique.
En termes de compatibilité, les images ReadyToRun sont similaires aux assemblys IL avec quelques différences clés.
- Les assemblys IL contiennent uniquement du code IL . Ils peuvent fonctionner dans n'importe quel environnement d'exécution prenant en charge l'infrastructure cible spécifiée pour cet assembly. Par exemple, la version
netstandard2.0 peut s'exécuter sur .NET Framework 4.6+ et .NET Core 2.0+, sur n'importe quel système d'exploitation pris en charge (Windows, macOS, Linux) et architecture (Intel, ARM, 32 bits, 64 bits). - Les assemblys R2R contiennent IL et du code natif. Ils sont compilés pour une version minimale spécifique du runtime .NET Core et de l'environnement d'exécution (RID). par exemple, la version
netstandard2.0 peut être compilée R2R pour .NET Core 3.0 et Linux x64. Il ne sera utilisé que dans cette configuration ou dans une configuration compatible (par exemple, .NET Core 3.1 ou .NET Core 5.0 sous Linux x64), car il contient du code natif qui ne peut être utilisé que dans cet environnement d'exécution.
Instructions
La compilation ReadyToRun est disponible pour publication uniquement. La version d'aperçu a été publiée dans .NET Core 3.0 (aperçu 5).
Pour activer la compilation ReadyToRun, vous devez:
- Définissez la valeur de la propriété
PublishReadyToRun sur true . - Publiez en utilisant le
RuntimeIdentifier exact.
Remarque Lorsque les versions de l'application sont compilées, le code natif généré dépend de la plate-forme et de l'architecture (par conséquent, lors de la publication, vous devez spécifier un RuntimeIdentifier valide).
Voici un exemple:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishReadyToRun>true</PublishReadyToRun> </PropertyGroup> </Project>
Et la publication à l'aide de la commande suivante:
dotnet publish -r win-x64 -c Release
Remarque: RuntimeIdentifier peut être défini dans le fichier de projet.
Remarque: ReadyToRun n'est actuellement pris en charge que pour les applications autonomes . Il sera ajouté pour les applications dépendantes du framework dans une annonce ultérieure.
La génération de caractères d' PublishReadyToRunEmitSymbols peut être activée en définissant la propriété PublishReadyToRunEmitSymbols sur true . Vous n'avez pas besoin de créer des caractères machine à des fins de débogage. Ces caractères ne sont utiles qu'à des fins de profilage.
Actuellement, le SDK prend en charge un moyen d'exclure certains assemblys de la compilation dans des images ReadyToRun. Cela peut être utile dans les cas où les assemblages n'ont pas besoin d'être optimisés pour améliorer les performances. L'exclusion d'assemblys dans ce cas peut aider à réduire la taille de l'application. Dans le cas où le compilateur ReadyToRun ne parvient pas à compiler un assembly spécifique, la solution peut également être de l'éliminer.
Une exception est levée à l'aide du groupe d'éléments PublishReadyToRunExclude:
<ItemGroup> <PublishReadyToRunExclude Include="FilenameOfAssemblyToExclude.dll" /> </ItemGroup>
Compilation multiplateforme / architecturale
Le compilateur ReadyToRun ne prend pas encore en charge le ciblage croisé. Vous devez compiler pour un objectif donné. Par exemple, si vous avez besoin d'images R2R pour Windows x64, vous devez exécuter la commande de publication dans cet environnement.
Exceptions:
- Windows x64 peut être utilisé pour compiler des images Windows ARM32, ARM64 et x86.
- Windows x86 peut être utilisé pour compiler des images Windows ARM32.
- Linux x64 peut être utilisé pour compiler des images Linux ARM32 et ARM64.
Disposition de l'assemblage
Le SDK NET core 3.0 est livré avec un outil qui peut réduire la taille des applications en analysant IL et en éliminant les versions inutilisées.
Avec .NET Core, vous pouvez toujours publier des applications autonomes qui incluent tout ce dont vous avez besoin pour exécuter votre code, sans avoir à installer .NET sur la cible de déploiement. Dans certains cas, l'application ne nécessite qu'un petit sous-ensemble du cadre, et elle pourrait être beaucoup plus petite en n'incluant que les bibliothèques utilisées.
Nous utilisons le générateur IL pour analyser l'IL de votre application afin de déterminer quel code est réellement requis, puis exclure les bibliothèques d'infrastructure inutilisées. Cela peut réduire considérablement la taille de certaines applications. En règle générale, les petites applications de console comme les outils tirent le meilleur parti, car elles utilisent souvent de petits sous-ensembles du cadre et se prêtent généralement bien au recadrage.
Pour utiliser cet outil, définissez PublishTrimmed=true dans votre projet et publiez l'application autonome:
dotnet publish -r <rid> -c Release
La sortie de publication comprendra un sous-ensemble des bibliothèques d'infrastructure, selon le code d'application qui invoque. Pour l'application helloworld, l'éditeur de liens réduit la taille de ~ 68 Mo à ~ 28 Mo.
Les applications ou les frameworks (y compris ASP.NET Core et WPF) qui utilisent la réflexion ou les fonctions dynamiques associées se cassent souvent lors du recadrage car l'éditeur de liens ignore ce comportement dynamique et ne peut généralement pas déterminer quels types de frameworks seront requis pour la réflexion lors de l'exécution . Pour recadrer de telles applications, vous devez indiquer à l'éditeur de liens tous les types nécessaires à la réflexion dans votre code et dans tous les packages ou environnements dont vous dépendez. Assurez-vous de tester vos applications après le recadrage.
Pour plus d'informations sur IL Linker, consultez la documentation ou visitez le référentiel mono / linker .
Remarque: Dans les versions précédentes de .NET Core, ILLink.Tasks était fourni en tant que package NuGet externe et offrait la plupart des mêmes fonctionnalités. Il n'est plus pris en charge - passez à la dernière version du SDK 3.0.
Linker et partage de l'éditeur de liens ReadToRun
Linker Linker et ReadyToRun Linker peuvent être utilisés pour la même application. En général, l'éditeur de liens rend votre application plus petite, puis le compilateur prêt à l'emploi la rendra un peu plus grande, mais avec un gain de performances significatif. Il vaut la peine de tester différentes configurations pour comprendre l'effet de chaque option.
Remarque: dotnet / sdk # 3257 empêche l'éditeur de liens et le partage ReadyToRun pour les applications WPF et Windows Forms. Nous travaillons à résoudre ce problème dans le cadre de la version .NET Core 3.0.
Exemple d'hébergement natif
Récemment publié un exemple d'hébergement natif . Il illustre la meilleure approche pour l'hébergement de .NET Core dans une application native.
Dans le cadre de .NET Core 3.0, nous fournissons désormais des fonctionnalités communes à nos propres services d'hébergement .NET Core, qui n'étaient auparavant disponibles que pour les applications gérées .NET Core via les services d'hébergement .NET Core officiellement fournis. La fonctionnalité est principalement associée au chargement de l'assemblage. Cette fonctionnalité devrait faciliter la création de vos propres services d'hébergement qui peuvent utiliser la gamme complète des fonctionnalités de .NET Core.
Prise en charge HTTP / 2 dans HttpClient
HTTP / 2 est la version principale du protocole HTTP. Certaines des caractéristiques notables de HTTP / 2 sont la prise en charge de la compression d'en-tête et les flux entièrement multiplexés sur une seule connexion. Bien que HTTP / 2 conserve la sémantique de HTTP (en-têtes HTTP, méthodes, etc.), il diffère de HTTP / 1.x dans la façon dont les données sont envoyées.
HttpClient prend désormais en charge les requêtes HTTP / 2. Par défaut, tout reste également HTTP / 1.1, mais vous pouvez le désactiver en faveur de HTTP / 2 en installant la version à l'aide d'une requête HTTP.
var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001") };
Vous pouvez également envoyer des demandes HTTP / 2 par défaut en définissant DefaultRequestVersion sur HttpClient .
var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001"), DefaultRequestVersion = new Version(2, 0) };
À la suite de ce changement, les serveurs et les clients doivent se mettre d'accord sur la version de protocole utilisée. ALPN (Application-Layer Protocol Negotiation) est une extension TLS qui permet au serveur et au client de négocier la version du protocole utilisée dans le cadre de leur interaction. Cependant, gardez à l'esprit que la plupart des serveurs ne prennent en charge ALPN que comme seul moyen d'établir une connexion HTTP / 2. Ainsi, HTTP / 2 est négocié par HttpClient uniquement sur la connexion TLS.
Dans les scénarios de développement, lorsque le serveur et le client savent a priori qu'ils parleront tous les deux HTTP / 2 sans chiffrement, vous pouvez établir une connexion HTTP / 2 via du texte clair en définissant le commutateur AppContext ou la variable d'environnement. ( DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1 ).
AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
Achèvement
Nous serons très heureux si vous essayez de nouvelles fonctionnalités. Veuillez signaler les problèmes ou bogues que vous rencontrez. Vous pouvez également soumettre des demandes de nouvelles fonctionnalités, mais leur mise en œuvre devra attendre la prochaine version.
Nous sommes maintenant sur le point d'achever les travaux sur le composant .NET Core 3.0 et nous attirons maintenant l'attention de l'équipe sur l'amélioration de la qualité des versions. Nous avons des mois à l'avance pour corriger les bogues et améliorer les performances.
Soit dit en passant, pour la prochaine mise à jour majeure, nous changerons les branches principales dans les référentiels .NET Core. Cela se produira très probablement immédiatement après l'aperçu 7 en juillet.
Merci d'avoir testé .NET Core 3.0. Nous apprécions votre aide. En ce moment, nous nous efforçons de faire de la version finale la plus intéressante et de haute qualité pour vous.