AOT en mode mixte, multi-threading, Web Crypto — Visual Studio Magazine

Nouvelles

Plans .NET 7 WebAssembly : AOT en mode mixte, multi-threading, Web Crypto

En créant .NET 7, Microsoft continuera d’améliorer les fonctionnalités de WebAssembly, la technologie derrière Blazor côté client, avec des plans pour renforcer la compilation Ahead Of Time (AOT), le multi-threading et la prise en charge de la cryptographie.

Blazor WebAssembly est le nom de ce composant côté client de Blazor, qui permet le codage Web en C # au lieu de JavaScript. WebAssembly sert de cible de compilation semblable à un langage d’assemblage pour exécuter du code C # dans le navigateur.

Avec le premier aperçu de la livraison de .NET 7 cette semaine, Microsoft a présenté ses plans pour la fonctionnalité WebAssembly dans un article sur les mises à jour d’ASP.NET Core, le framework de développement Web où vit Blazor. Si mesuré par le nombre d’éléments de travail dans la feuille de route ASP.NET Core pour .NET 7, Blazor attire de loin la part du lion de l’attention des développeurs.

Selon l’article de cette semaine, parmi les domaines dans lesquels de larges améliorations sont apportées au cycle de développement de .NET 7, citons : “Nouvelles fonctionnalités de .NET WebAssembly : AOT en mode mixte, multithreading, cryptographie Web.”

AOT en mode mixte
La fonctionnalité entourant ce premier élément est présente depuis un certain temps maintenant, car AOT est venu à Blazor en mai dernier dans un aperçu .NET 6. À l’époque, Daniel Roth, responsable principal du programme pour ASP.NET, a déclaré : “Blazor WebAssembly prend désormais en charge la compilation Ahead-Of-Time (AOT), où vous pouvez compiler votre code .NET directement sur WebAssembly pour une amélioration significative des performances d’exécution. Les applications Blazor WebAssembly s’exécutent aujourd’hui à l’aide d’un interpréteur .NET IL implémenté dans WebAssembly.Parce que le code .NET est interprété, cela signifie généralement que le code .NET s’exécutant sur WebAssembly s’exécute beaucoup plus lentement qu’il ne le ferait sur une exécution .NET normale. compilation résout ce problème de performances en compilant votre code .NET directement dans WebAssembly.”

L’AOT en mode mixte consiste à prendre des parties du code IL (langage intermédiaire) et à le compiler en WebAssembly pour qu’il soit exécuté dans le navigateur. Il est en deçà de l’AOT “complet”, ce qui ne peut pas être fait dans Blazor pour des raisons techniques.

L’élément “AOT en mode mixte” dans le message d’annonce rédigé par Roth a été remis en question dans un commentaire de lecteur :

Blazor n’a pas encore d’AOT complet, comme indiqué dans Blazor AOT .Net6 Preview 7 – Toujours en train de télécharger les Dll # 35302, mais ce problème est clos et l’AOT complet est marqué comme terminé (les développeurs peuvent AOT compiler les applications .NET au format WebAssembly), et maintenant Microsoft passe à l’AOT mixte comme si l’AOT complet était déjà là. L’AOT complet est assez essentiel pour déployer des applications sur des navigateurs avec de bonnes performances de démarrage et une bonne taille de fichier. Je pense qu’il vaut mieux que les développeurs qui souhaitent déployer des applications sur des navigateurs abandonnent Blazor et se concentrent sur le travail effectué dans runtimelab sur NativeAOT WASM, ce qui semble beaucoup plus proche d’avoir une chaîne d’outils de compilation wasm utilisable.

Voici la réponse de Roth :

Vous avez raison de dire que nous nous appuyons toujours sur l’interprétation .NET IL dans certains cas lors de l’utilisation de la compilation anticipée (AOT) pour WebAssembly. En effet, certaines fonctionnalités d’exécution .NET l’exigent toujours. Donc, dans ce cas, AOT “complet” signifie vraiment que nous compilons AOT autant que nous le pouvons. Des travaux sont en cours pour améliorer encore WebAssembly AOT afin de réduire le besoin d’utiliser l’interpréteur, mais il est peu probable que nous puissions le supprimer complètement étant donné les limitations imposées actuellement par WebAssembly.

Veuillez également noter que si la taille du téléchargement est un problème, la compilation AOT en général ne va pas aider même si nous pouvions supprimer complètement le besoin d’interprétation. Le code compilé AOT est généralement plus volumineux que les instructions .NET IL d’origine, environ 2 fois plus volumineux. Au fur et à mesure que nous réduisons davantage le besoin d’interprétation, nous pouvons réduire quelque peu la taille de l’application en réduisant davantage les assemblages .NET, mais l’application sera toujours plus grande que si elle n’utilisait pas du tout AOT. La compilation WebAssembly AOT aide à améliorer les performances d’exécution pour les travaux intensifs du processeur.

Nous sommes également conscients du travail de backend de NativeAOT LLVM et sommes impatients de voir comment cela se passe !

Le manque d’AOT natif est un problème de .NET Core depuis un certain temps, avec Microsoft en 2020 publiant les résultats d’une enquête indiquant que le manque d’AOT empêchait les développeurs d’utiliser davantage .NET Core.

Multi-threading
Le problème de multi-threading, quant à lui, a été résolu depuis décembre 2019 lorsqu’un problème a été ouvert appelant à “le multithreading qui est déjà disponible dans WEBASM pour être exposé au côté Blazor Client”. Plus de deux ans – et 69 commentaires – plus tard, Roth a publié le dernier commentaire sur le fil : « La prise en charge du multithreading dans Blazor WebAssembly est prévue pour .NET 7. Les plans peuvent encore changer, nous verrons donc comment cela se passe. “

Crypto Web
Cela découle d’un numéro de juillet 2020 : “Les développeurs ciblant le navigateur-wasm peuvent utiliser les API Web Crypto.” Il indique que l’équipe de développement aimerait utiliser les fonctions de cryptage natives de la plate-forme et éviter d’expédier OpenSSL pour le navigateur.

Il pointe également vers la documentation de SubtleCrypto, qui dit : « L’interface SubtleCrypto de l’API Web Crypto fournit un certain nombre de fonctions cryptographiques de bas niveau. L’accès aux fonctionnalités de SubtleCrypto est obtenu grâce à la propriété subtile de l’objet Crypto que vous obtenez du crypto. propriété.” Mozilla dit que l’API Web Crypto est une interface permettant à un script d’utiliser des primitives cryptographiques afin de construire des systèmes utilisant la cryptographie.

Mais d’abord, Blazor hybride
Notez que Roth a déclaré que tout le travail ci-dessus était prévu pour “Après avoir terminé la prise en charge de Blazor Hybrid pour .NET MAUI, WPF et Windows Forms”. Les applications Blazor Hybrid sont des applications natives qui peuvent tirer parti des technologies Web telles que HTML et CSS pour des fonctionnalités supplémentaires. Ainsi, une application hybride peut utiliser un contrôle WebView intégré pour rendre l’interface utilisateur Web tout en tirant parti des capacités natives de l’appareil, comme expliqué dans le mois dernier Magazine Visual Studio article “Modifier les images/textes locaux à partir d’une application hybride .NET MAUI Blazor.”

Vous pouvez en savoir plus sur les nouveautés de Blazor Hybrid dans .NET 7 dans l’article intitulé “What’s Coming for Blazor Hybrid in .NET 7”.

Roth’s fév. 17 post sur les mises à jour ASP.NET Core dans .NET 7 Preview 1 indique qu’une fois ce travail terminé, d’autres améliorations pour Blazor (en plus des éléments AOT) incluent :

• Prise en charge améliorée du rechargement à chaud
• Améliorations de la liaison de données
• Prérendu plus flexible
• Plus de contrôle sur le cycle de vie des circuits Blazor Server
• Prise en charge améliorée des micro-interfaces

Les autres domaines ASP.NET Core pour lesquels des investissements de développement sont décrits par Roth incluent :

• Performance: .NET 6 contenait de nombreuses améliorations de performances pour ASP.NET Core, et nous travaillerons pour rendre ASP.NET Core encore plus rapide et plus efficace dans .NET 7.
• HTTP/3: prise en charge de HTTP/3 livrée en tant que fonctionnalité d’aperçu dans .NET 6. Pour .NET 7, nous souhaitons la terminer et en faire une fonctionnalité prise en charge activée par défaut. Dans les futurs aperçus, vous pouvez vous attendre à voir des fonctionnalités TLS avancées et d’autres améliorations de performances dans notre prise en charge HTTP/3.
• API minimales: Ajout de la prise en charge des filtres de point de terminaison et du regroupement de routes en tant que primitives de base pour les API minimales. Simplifiez également les configurations d’authentification et d’autorisation pour les API en général.
• gRPC: Nous investissons dans le transcodage gRPC JSON. Cette fonctionnalité permet aux services gRPC d’être appelés comme des API HTTP RESTful avec des requêtes et des réponses JSON.
• SignalR: Ajout de la prise en charge des clients fortement typés et retour des résultats des invocations client.
• Le rasoir: Nous apporterons diverses améliorations au compilateur Razor pour améliorer les performances, la résilience et faciliter l’amélioration de l’outillage.
• MVC: Améliorations du routage des points de terminaison, de la génération de liens et de la liaison des paramètres.
• Orléans: Les équipes ASP.NET Core et Orléans étudient les moyens d’aligner et d’intégrer davantage le modèle de programmation distribuée Orléans avec ASP.NET Core. Orleans 4 sera livré avec .NET 7 et se concentre sur la simplicité, la maintenabilité et les performances, y compris des identités de flux lisibles par l’homme et un nouveau sérialiseur optimisé et tolérant les versions.

Les nouveautés de l’aperçu 1, quant à elles, étaient répertoriées comme suit :

• Améliorations minimales de l’API :

  • Prise en charge de IFormFile et IFormFileCollection
  • Lier le corps de la requête en tant que Stream ou PipeReader
  • Configuration des options JSON
• Générateur de source client SignalR
• Prise en charge des modèles nullables dans les vues MVC et les pages Razor
• Utiliser les noms de propriété JSON dans les erreurs de validation
• Amélioration de la sortie de la console pour la surveillance dotnet
• Configurez dotnet watch pour qu’il redémarre toujours en cas de modifications grossières
• Utiliser l’injection de dépendance dans un ValidationAttribute
• Analyse et écriture d’en-tête plus rapides
• Transcodage gRPC JSON

« Nous espérons que vous apprécierez cette version préliminaire d’ASP.NET Core dans .NET 7 et que vous êtes aussi enthousiasmé par notre feuille de route pour .NET 7 que nous le sommes ! dit Roth en conclusion. “Nous sommes impatients de connaître vos expériences avec cette version et vos réflexions sur la feuille de route. Faites-nous savoir ce que vous pensez en signalant les problèmes sur GitHub et en commentant le problème de la feuille de route.”