ASP.NET Core Blazor WebAssembly-Buildtools und Ahead-of-Time-Kompilierung (AOT)

In diesem Artikel werden die Buildtools für eigenständige Blazor WebAssembly-Apps und das Kompilieren einer App vor der Bereitstellung mit Ahead-of-Time-Kompilierung (AOT) beschrieben.

Der Schwerpunkt des Artikel liegt zwar hauptsächlich auf eigenständigen Blazor WebAssembly-Apps, der Abschnitt zur Heapgröße für einige Browser auf mobilen Geräten gilt aber auch für das clientseitige Projekt (.Client) einer Blazor-Web-App.

.NET WebAssembly-Buildtools

Die .NET-WebAssembly-Buildtools basieren auf Emscripten, einer Compilertoolkette für die Webplattform. Verwenden Sie eine der folgenden Methoden, um die Buildtools zu installieren:

• Wählen Sie für die Workload ASP.NET und Webentwicklung im Visual Studio-Installer aus der Liste der optionalen Komponenten die Option .NET WebAssembly build tools (.NET-WebAssembly-Buildtools) aus.
• Führen Sie dotnet workload install wasm-tools in einer Verwaltungsbefehlsshell aus.

Hinweis

.NET WebAssembly-Buildtools für .NET 6-Projekte

Die wasm-tools-Workload installiert die Buildtools für das aktuelle Release. Die aktuelle Version der Buildtools ist jedoch nicht mit vorhandenen Projekten kompatibel, die mit .NET 6 erstellt wurden. Projekte, die Buildtools verwenden, die sowohl .NET 6 als auch höhere Releases unterstützen müssen, müssen die Festlegung von Zielversionen verwenden.

Verwenden Sie die wasm-tools-net6-Workload für .NET 6-Projekte beim Entwickeln von Apps mit dem .NET 7 SDK. Um die wasm-tools-net6-Workload zu installieren, führen Sie den folgenden Befehl aus über eine Verwaltungsbefehlsshell aus:

dotnet workload install wasm-tools-net6

Ahead-of-Time-Kompilierung (AOT)

Blazor WebAssembly unterstützt die AOT-Kompilierung, mit der Sie Ihren .NET-Code direkt in WebAssembly kompilieren können. Die AOT-Kompilierung verbessert die Runtimeleistung, allerdings nimmt die Größe der App zu.

Wenn die AOT-Kompilierung deaktiviert ist, werden Blazor WebAssembly-Apps mithilfe eines in WebAssembly implementierten Interpreters für die .NET-Zwischensprache (Intermediate Language, IL) mit partieller JIT-Runtimeunterstützung (Just-In-Time) informell als Jiterpreter bezeichnet, im Browser ausgeführt. Da der .NET-IL-Code interpretiert wird, werden Apps in der Regel langsamer ausgeführt als mit einer serverseitigen JIT-Runtime für .NET ohne IL-Interpretation. Die AOT-Kompilierung löst dieses Leistungsproblem, indem der .NET-Code einer App direkt in WebAssembly kompiliert wird, um die native WebAssembly-Ausführung durch den Browser zu ermöglichen. Die AOT-Leistungsverbesserung kann zu erheblichen Verbesserungen für Apps führen, die CPU-intensive Tasks ausführen. Der Nachteil bei der AOT-Kompilierung besteht darin, dass mit dem AOT-Ansatz kompilierte Apps im Allgemeinen größer sind als die mit einer Zwischensprache interpretierten Entsprechungen. Dadurch dauert das Herunterladen auf den Client bei der ersten Anforderung in der Regel länger.

Anweisungen zum Installieren der .NET WebAssembly-Buildtools finden Sie unter ASP.NET Core Blazor WebAssembly-Buildtools und Ahead-of-Time-Kompilierung (AOT).

Um die WebAssembly-AOT-Kompilierung zu aktivieren, fügen Sie der Projektdatei der Blazor WebAssembly-App die auf true festgelegte Eigenschaft <RunAOTCompilation> hinzu:

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

Veröffentlichen Sie die App, um die App in WebAssembly zu kompilieren. Durch die Veröffentlichung der Konfiguration Release wird sichergestellt, dass auch die Verknüpfung der .NET-Zwischensprache ausgeführt wird, um die Größe der veröffentlichten App zu reduzieren:

dotnet publish -c Release

Die AOT-Kompilierung für WebAssembly erfolgt nur, wenn das Projekt veröffentlicht wird. Die AOT-Kompilierung wird nicht verwendet, wenn das Projekt während der Entwicklung (Development-Umgebung) ausgeführt wird, da die AOT-Kompilierung bei kleinen Projekten in der Regel mehrere Minuten und bei größeren Projekten ggf. viel länger dauert. Für zukünftige Releases von ASP.NET Core ist geplant, die Buildzeit für die AOT-Kompilierung zu reduzieren.

Eine mit dem AOT-Ansatz kompilierte Blazor WebAssembly-App ist im Allgemeinen größer als eine App, die in .NET IL kompiliert wird:

• Obwohl der Größenunterschied von der App abhängt, sind die meisten mit dem AOT-Ansatz kompilierten Apps ungefähr doppelt so groß wie die mit der Zwischensprache kompilierten Versionen. Das bedeutet, dass bei der AOT-Kompilierung Einbußen bei der Ladezeit zugunsten der Runtimeleistung in Kauf genommen werden. Ob dieser Kompromiss die Verwendung der AOT-Kompilierung rechtfertigt, hängt von Ihrer App ab. CPU-intensive Blazor WebAssembly-Apps profitieren in der Regel am meisten von der AOT-Kompilierung.

• Die größere Größe einer App mit AOT-Kompilierung ist auf zwei Bedingungen zurückzuführen:

  • Es ist mehr Code erforderlich, um allgemeine .NET IL-Anweisungen in nativem WebAssembly darzustellen.
  • AOT kürzt nicht die verwalteten DLLs, wenn die App veröffentlicht wird. Blazor benötigt die DLLs für Reflexionsmetadaten und zur Unterstützung bestimmter .NET-Runtimefeatures. Wenn Sie die DLLs auf dem Client benötigen, erhöht sich zwar die Downloadgröße, aber Sie erhalten eine kompatiblere .NET-Erfahrung.

Hinweis

Informationen zu Mono/WebAssembly-MSBuild-Eigenschaften und -Zielen finden Sie unter WasmApp.Common.targets (im GitHub-Repository „dotnet/runtime“). Die offizielle Dokumentation zu MSBuild-Eigenschaften ist für das Dokument zu Blazor-MSBuild-Konfigurationsoptionen (dotnet/docs #27395) geplant.

Kürzen von .NET-Zwischensprache nach der AOT-Kompilierung (Ahead-of-Time)

Die MSBuild-Option WasmStripILAfterAOT ermöglicht das Entfernen der .NET-Zwischensprache (Intermediate Language, IL) für kompilierte Methoden nach der AOT-Kompilierung in WebAssembly, wodurch die Größe des _framework-Ordners reduziert wird.

In der Projektdatei der App:

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

Diese Einstellung entfernt den IL-Code für die meisten kompilierten Methoden, einschließlich Methoden aus Bibliotheken und Methoden in der App. Nicht alle kompilierten Methoden können gekürzt werden, da einige noch vom .NET-Interpreter zur Laufzeit benötigt werden.

Um ein Problem mit der Option zum Kürzen zu melden, können Sie ein Issue im GitHub-Repository dotnet/runtime öffnen.

Deaktivieren Sie die trimming-Eigenschaft, wenn sie verhindert, dass Ihre App normal ausgeführt wird:

<WasmStripILAfterAOT>false</WasmStripILAfterAOT>

Heapgröße für einige Browser auf mobilen Geräten

Beim Erstellen einer Blazor-App, die auf dem Client ausgeführt wird und auf Browser für mobile Geräte ausgerichtet ist (insbesondere Safari unter iOS), kann es erforderlich sein, den maximalen Arbeitsspeicher für die App mit der MSBuild-Eigenschaft EmccMaximumHeapSize zu reduzieren. Weitere Informationen finden Sie unter Hosten und Bereitstellen von Blazor WebAssembly in ASP.NET Core.

Neuverknüpfung der Runtime

Zu den größten Komponenten einer Blazor WebAssembly-App zählt die WebAssembly-basierte .NET-Runtime (dotnet.wasm), die der Browser herunterladen muss, wenn die App zum ersten Mal aufgerufen wird. Durch die Neuverknüpfung der WebAssembly-basierten .NET-Runtime wird nicht verwendeter Runtimecode gekürzt, um die Downloadgeschwindigkeit zu steigern.

Für die Neuverknüpfung der Runtime müssen die .NET WebAssembly-Buildtools installiert werden. Weitere Informationen finden Sie unter Tools für ASP.NET Core Blazor.

Wenn die .NET WebAssembly-Buildtools installiert sind, wird die Neuverknüpfung der Runtime automatisch ausgeführt, sobald in der Release-Konfiguration eine App veröffentlicht wird. Wenn Sie die Globalisierung deaktivieren, ist die Größenreduzierung besonders drastisch. Weitere Informationen finden Sie unter Blazor in ASP.NET Core: Globalisierung und Lokalisierung.

Wichtig

Durch die erneute Verknüpfung der Runtime werden durch die JavaScript-Klasseninstanz aufrufbare .NET-Methoden gekürzt, sofern sie nicht geschützt sind. Weitere Informationen finden Sie unter Aufrufen von .NET-Methoden über JavaScript-Funktionen in ASP.NET Core Blazor.

SIMD (Single Instruction Multiple Data)

Single Instruction Multiple Data (SIMD) für WebAssembly kann den Durchsatz vektorisierter Berechnungen verbessern, indem ein Vorgang mit mehreren Datenteilen parallel in einer einzigen Anweisung ausgeführt wird. SIMD ist standardmäßig aktiviert.

Um SIMD zu deaktivieren, z. B. beim Ziel von alten Browsern oder Browsern auf mobilen Geräten, die SIMD nicht unterstützen, legen Sie die <WasmEnableSIMD>-Eigenschaft in der Projektdatei der App (.csproj) auf false fest:

<PropertyGroup>
  <WasmEnableSIMD>false</WasmEnableSIMD>
</PropertyGroup>

Weitere Informationen finden Sie unter Konfigurieren und Hosten von .NET WebAssembly-Anwendungen: SIMD – Einzelanweisung, mehrere Daten und beachten Sie, dass die Anleitung nicht versioniert ist und für die neueste öffentliche Version gilt.

Ausnahmebehandlung

Die Ausnahmebehandlung ist standardmäßig aktiviert. Fügen Sie zum Deaktivieren der Ausnahmebehandlung die <WasmEnableExceptionHandling>-Eigenschaft in der Projektdatei der App (.csproj) mit dem Wert false hinzu:

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

Zusätzliche Ressourcen

• ASP.NET Core Blazor WebAssembly: native Abhängigkeiten
• Webcil-Paketerstellungsformat für .NET-Assemblys