Pas besoin d’attendre .NET 8 pour essayer le multithreading WebAssembly expérimental – Visual Studio Magazine

Nouvelles

Pas besoin d’attendre .NET 8 pour essayer le multithreading WebAssembly expérimental

La prise en charge du multithreading pour les applications Blazor WebAssembly côté client est prévue pour .NET 8 en novembre 2023, mais les développeurs peuvent l’essayer maintenant pour les applications .NET grâce aux fonctionnalités expérimentales de la toute nouvelle .NET 7 Release Candidate 2.

Annoncé aujourd’hui, .NET 7 RC2 est un code prêt pour la production à seulement un mois de la disponibilité générale.

Aujourd’hui également, Microsoft a publié un article de blog expliquant les mises à jour d’ASP.NET Core dans .NET 7 Release Candidate 2. Tout comme dans .NET 7 RC1, WebAssembly était la vedette de cette émission ASP.NET Core.

RC1 a reçu une foule d’améliorations pour WebAssembly, la technologie open source qui alimente la partie côté client de Blazor – bien nommée Blazor WebAssembly – et permet aux projets Web d’être codés principalement en C # au lieu de JavaScript. RC1 comportait des demandes d’authentification dynamiques dans Blazor WebAssembly, des améliorations de débogage, des outils de création .NET WebAssembly pour les projets .NET 6 et une interopérabilité JavaScript .NET sur WebAssembly.

Ce dernier élément est fourni via un nouveau modèle expérimental, wasm-experimentalavec Microsoft déclarant : “.NET 7 introduit un nouveau mécanisme de bas niveau pour l’utilisation de .NET dans les applications basées sur JavaScript. Grâce à cette nouvelle capacité d’interopérabilité JavaScript, vous pouvez également appeler du code .NET à partir de JavaScript à l’aide de l’environnement d’exécution .NET WebAssembly [as] appeler la fonctionnalité JavaScript à partir de .NET sans aucune dépendance au modèle de composant d’interface utilisateur Blazor.”

Dans RC2, l’équipe de développement a amélioré le wasm-experimental Fonctionnalité.

“La wasm-experimental La charge de travail inclut désormais la prise en charge des applications .NET multithread sur WebAssembly à l’aide de Web Workers », a déclaré Microsoft aujourd’hui. « Il s’agit d’une nouvelle fonctionnalité d’exécution .NET. La prise en charge du multithreading n’a pas encore été intégrée dans les applications Blazor WebAssembly (prévues pour .NET 8), mais vous pouvez toujours l’essayer sous forme d’aperçu à l’aide du modèle expérimental WebAssembly Browser App.”

Feuille de route Blazor pour .NET 7
[Click on image for larger view.] Feuille de route Blazor pour .NET 7 (source : Microsoft).

Les autres faits saillants du poste comprennent:

  • Améliorations de la mise en cache de sortie : “La mise en cache de sortie a été améliorée dans .NET 7 RC2 en fonction des commentaires des utilisateurs. Dans cette version, la mise en cache de sortie stocke le contenu des entrées mises en cache dans un format binaire. Auparavant, elle utilisait JSON. Ce nouveau format est plus rapide et plus petit.”
  • Requêtes d’authentification dynamique avec msal.js : Dans .NET 7 RC1, nous avons introduit la prise en charge des demandes d’authentification dynamiques avec des paramètres personnalisés dans les applications Blazor WebAssembly. Avec .NET 7 RC2, cette fonctionnalité est désormais disponible lors de l’utilisation de Microsoft Identity Platform via l’intégration msal.js intégrée. Pour plus de détails sur les demandes d’authentification dynamiques dans Blazor WebAssembly, consultez la section Demandes d’authentification dynamiques dans Blazor WebAssembly du message d’annonce de la version .NET 7 RC1.
  • Diagnostics améliorés pour l’authentification dans Blazor WebAssembly : Pour aider à diagnostiquer les problèmes d’authentification dans les applications Blazor WebAssembly, nous avons ajouté une journalisation détaillée que vous pouvez activer.

Cependant, comme la capacité de multithreading peut être d’un intérêt particulier pour les développeurs, ils pourraient être informés que Microsoft a publié une longue liste de notes et de problèmes connus avec le multithreading .NET sur WebAssembly :

  • Par défaut, l’application créera un pool de quatre Web Workers pour exécuter les threads .NET. Pour contrôler le nombre de nœuds de calcul créés au démarrage de l’application, configurez le _WasmPThreadPoolSize propriété (sujet à changement dans une future version). Le parallélisme maximal de votre application ne doit pas dépasser la taille du pool de nœuds de calcul.
  • UN SynchronizationContext est utilisé sur le thread du navigateur par défaut. Si vous n’utilisez pas ConfigureAwait(false) en attente d’opérations asynchrones, elles seront ordonnancées sur le thread du navigateur. A l’inverse, ne pas utiliser ConfigureAwait permet à vos opérations asynchrones de revenir au thread du navigateur afin d’interagir avec le DOM ou d’autres bibliothèques JS qui ne sont disponibles que sur le thread principal.
  • Le multithreading nécessite que l’isolation entre les origines soit activée en servant les en-têtes COOP et COEP. Cela restreindra la fonctionnalité du site : l’activation de l’isolation d’origine croisée bloque le chargement de ressources d’origine croisée que vous n’acceptez pas explicitement, et cela empêchera votre document de niveau supérieur de pouvoir communiquer avec des fenêtres contextuelles.
  • Les propriétés de construction RunAOTCompilation et WasmEnableSIMD sont pris en charge avec le multithreading.
  • JSImport et JSExport ne fonctionnent qu’à partir du fil de navigation principal.
  • Les opérations WebSocket ne sont prises en charge que sur le thread de navigateur principal.
  • Le débogage de code multithread sur WebAssembly n’est pas encore pris en charge.
  • Le threading ne fonctionne pas encore dans Firefox à cause du Bugzilla #1540913.

L’origine de l’effort expérimental vient de ce problème GitHub, qui note qu’il a été terminé dans .NET 7 RC2 et déclare : “Le wasm-experimental la charge de travail prend en charge le threading à l’aide true en interp [sic] et les configurations AOT lors de l’utilisation de wasmbrowser charge de travail. Blazor ne prend pas en charge le threading dans .NET 7.”

A propos de l’auteur

David Ramel est éditeur et rédacteur pour Converge360.

.

Leave a Comment

Your email address will not be published. Required fields are marked *