Partager via

Outils de build Blazor WebAssembly ASP.NET Core et compilation anticipée (AOT)

Remarque

Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 10 de cet article.

Avertissement

Cette version d’ASP.NET Core n’est plus prise en charge. Pour plus d’informations, consultez la stratégie de prise en charge de .NET et .NET Core. Pour la version actuelle, consultez la version .NET 10 de cet article.

Cet article décrit les outils de build pour les applications Blazor WebAssembly autonomes et la façon de compiler une application avant le déploiement avec la compilation anticipée (AOT).

.NET WebAssembly Build Tools

Les outils de build WebAssembly .NET sont basés sur Emscripten, une chaîne d’outils de compilateur pour la plateforme web.

Pour installer les outils de génération en tant que charge de travail .NET, utilisez l’une des approches suivantes :

  • Pour la charge de travail ASP.NET et développement web dans le programme d’installation de Visual Studio, sélectionnez l’option Outils de build WebAssembly .NET dans la liste des composants facultatifs. L’option garantit les éléments suivants :

    • La charge de travail est installée pour le dernier Kit de développement logiciel (SDK) .NET.
    • Lorsqu’une nouvelle version de Visual Studio est publiée et qu’elle contient un nouveau Kit de développement logiciel (SDK) .NET, l’option installe la charge de travail pour le nouveau Kit de développement logiciel (SDK).

  • Vous pouvez également exécuter la commande suivante dans un interpréteur de commandes d’administration pour installer la charge de travail la plus récente vers le dernier SDK .NET disponible sur le système :

    dotnet workload install wasm-tools

Pour cibler une version précédente de .NET avec un SDK .NET donné, installez le wasm-tools-net{MAJOR VERSION} workload :

  • L’espace {MAJOR VERSION} réservé est remplacé par le numéro de version principal de la version .NET que vous souhaitez cibler (par exemple, wasm-tools-net8 pour .NET 8).
  • Les charges de travail sont installées par chaque SDK .NET. L’installation de la wasm-tools charge de travail d’un SDK ne le rend pas disponible pour d’autres kits SDK sur le système.
  • Vous devez installer la charge de travail appropriée pour chaque version du Kit de développement logiciel (SDK) .NET que vous envisagez d’utiliser.

La liste suivante montre la charge de travail à installer pour chaque KIT SDK .NET, en fonction des applications que vous envisagez de cibler. Bien que plusieurs lignes contiennent le même nom de charge de travail, les charges de travail diffèrent toujours légèrement pour chaque KIT SDK .NET particulier.

  • Utilisation du Kit de développement logiciel (SDK) .NET 10
    • Le ciblage de .NET 10 nécessite wasm-tools.
    • Le ciblage de .NET 9 nécessite wasm-tools-net9.
    • Le ciblage de .NET 8 nécessite wasm-tools-net8.
  • Utilisation du Kit de développement logiciel (SDK) .NET 9
    • Le ciblage de .NET 9 nécessite wasm-tools.
    • Le ciblage de .NET 8 nécessite wasm-tools-net8.
  • L’utilisation du Kit de développement logiciel (SDK) .NET 8 : le ciblage de .NET 8 nécessite wasm-tools.

Compilation anticipée (AOT)

Blazor WebAssembly prend en charge la compilation anticipée (AOT), qui permet de compiler le code .NET directement en WebAssembly. La compilation AOT permet d’améliorer les performances du runtime au détriment d’une plus grande taille d’application.

Sans activation de la compilation AOT, les applications Blazor WebAssembly s’exécutent sur le navigateur à l’aide d’un interpréteur de langage intermédiaire (IL) .NET implémenté en WebAssembly avec une prise en charge partielle du runtime juste-à-temps (JIT), qui est appelé de façon informelle Jiterpreter. Étant donné que le code IL .NET est interprété, les applications s’exécutent généralement plus lentement qu’elles le feraient sur un runtime juste-à-temps .NET côté serveur sans interprétation d’IL. La compilation AOT résout ce problème de performances en compilant le code .NET d’une application directement en WebAssembly pour l’exécution native de WebAssembly par le navigateur. L’amélioration des performances avec la compilation AOT peut apporter des améliorations spectaculaires pour les applications qui exécutent des tâches sollicitant beaucoup l’UC. L’inconvénient de l’utilisation de la compilation AOT est que les applications avec compilation AOT sont généralement plus volumineuses que leurs équivalents interprétés par le langage intermédiaire, de sorte qu’elles prennent généralement plus de temps à se télécharger sur le client lors de la première requête.

Sans activer la compilation AOT, les applications Blazor WebAssembly s’exécutent sur le navigateur à l’aide d’un interpréteur de langage intermédiaire (IL) .NET implémenté en WebAssembly. Étant donné que le code .NET est interprété, les applications s’exécutent généralement plus lentement qu’elles le feraient sur un runtime juste-à-temps (JIT) .NET côté serveur. La compilation AOT résout ce problème de performances en compilant le code .NET d’une application directement en WebAssembly pour l’exécution native de WebAssembly par le navigateur. L’amélioration des performances avec la compilation AOT peut apporter des améliorations spectaculaires pour les applications qui exécutent des tâches sollicitant beaucoup l’UC. L’inconvénient de l’utilisation de la compilation AOT est que les applications avec compilation AOT sont généralement plus volumineuses que leurs équivalents interprétés par le langage intermédiaire, de sorte qu’elles prennent généralement plus de temps à se télécharger sur le client lors de la première requête.

Pour obtenir des conseils sur l’installation des outils de build WebAssembly .NET, consultez Outils de build Blazor WebAssembly ASP.NET Core et compilation anticipée (AOT).

Pour activer la compilation AOT en WebAssembly, ajoutez la propriété <RunAOTCompilation> définie sur true au fichier projet de l’application Blazor WebAssembly :

<PropertyGroup>
  <RunAOTCompilation>true</RunAOTCompilation>
</PropertyGroup>

Pour compiler l’application en WebAssembly, publiez l’application. La publication de la configuration Release garantit que la liaison en langage intermédiaire (IL) .NET est également exécutée pour réduire la taille de l’application publiée :

dotnet publish -c Release

La compilation AOT en WebAssembly n’est effectuée que lorsque le projet est publié. La compilation AOT n’est pas utilisée lorsque le projet est exécuté pendant le développement (environnement Development), car la compilation AOT prend généralement plusieurs minutes sur de petits projets, et peut être beaucoup plus longue pour les projets plus volumineux. La réduction du temps de build pour la compilation AOT est en cours de développement pour les versions futures d’ASP.NET Core.

La taille d’une application Blazor WebAssembly avec compilation AOT est généralement supérieure à la taille de l’application si elle est compilée en langage intermédiaire .NET :

  • Bien que la différence de taille dépende de l’application, la plupart des applications avec compilation AOT ont environ deux fois la taille de leurs versions compilées en langage intermédiaire. Cela signifie que l’utilisation de la compilation AOT représente un compromis entre les performances de temps de charge et les performances d’exécution. Votre application particulière détermine si ce compromis vaut la peine d’utiliser la compilation AOT. Les applications Blazor WebAssembly gourmandes en processeur bénéficient généralement le plus de la compilation AOT.

  • La plus grande taille d’une application compilée par AOT est due à deux conditions :

    • Plus de code est nécessaire pour représenter les instructions en langage intermédiaire .NET de haut niveau en WebAssembly natif.
    • AOT ne supprime pas les DLL managées lors de la publication de l’application. Blazor nécessite les DLL pour les métadonnées de réflexion et pour prendre en charge certaines fonctionnalités de runtime .NET. L’utilisation des DLL sur le client augmente la taille du téléchargement, mais offre une expérience .NET plus compatible.

Remarque

Pour les propriétés et les cibles Mono/WebAssembly MSBuild, consultez WasmApp.Common.targets (dépôt GitHub dotnet/runtime). La documentation officielle pour les propriétés MSBuild courantes est planifiée conformément au Document des options de configuration MSBuild pour Blazor (dotnet/docs nº 27395).

Performances

Pour obtenir des conseils sur les performances, consultez les performances du runtime d'ASP.NET Core Blazor WebAssembly:

  • Taille du tas pour certains navigateurs d’appareils mobiles
  • Nouvelle liaison du runtime
  • Instruction unique, plusieurs données (SIMD)
  • Réduction de .NET IL après la compilation anticipée (AOT) (.NET 8 ou version ultérieure)

Gestion des exceptions

La gestion des exceptions est activée par défaut. Pour désactiver la gestion des exceptions, ajoutez la propriété <WasmEnableExceptionHandling> avec la valeur false dans le fichier projet de l’application (.csproj) :

<PropertyGroup>
  <WasmEnableExceptionHandling>false</WasmEnableExceptionHandling>
</PropertyGroup>

Pour activer la gestion des exceptions WebAssembly, ajoutez la propriété <WasmEnableExceptionHandling> avec la valeur true dans le fichier projet de l’application (.csproj :

<PropertyGroup>
  <WasmEnableExceptionHandling>true</WasmEnableExceptionHandling>
</PropertyGroup>

Pour en savoir plus, consultez les ressources suivantes :

Ressources supplémentaires

  • Last updated on