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.

.NET WebAssembly-Buildtools

Die .NET-WebAssembly-Buildtools basieren auf Emscripten, einer Compilertoolkette für die Webplattform.

Um die Buildtools als .NET-Workload zu installieren, verwenden Sie eine der folgenden Ansätze:

• 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. Die Option stellt Folgendes sicher:

  • Die Arbeitslast wird für die neueste Version des .NET SDK installiert.
  • Wenn eine neue Version von Visual Studio veröffentlicht wird und ein neues .NET SDK enthält, installiert die Option die Workload für das neue SDK.

• Führen Sie alternativ den folgenden Befehl in einer Verwaltungsbefehlsshell aus, um die neueste Workload auf das neueste .NET SDK zu installieren, das auf dem System verfügbar ist:

  dotnet workload install wasm-tools
  

Um eine frühere .NET-Version mit einem bestimmten .NET SDK anzusteuern, installieren Sie die wasm-tools-net{MAJOR VERSION} Workload:

• Der {MAJOR VERSION} Platzhalter wird durch die Hauptversionsnummer der .NET-Version ersetzt, wasm-tools-net8 auf die Sie abzielen möchten (z. B. für .NET 8).
• Workloads werden pro .NET SDK installiert. Die Installation der wasm-tools Workload für ein SDK macht sie nicht für andere SDKs auf dem System verfügbar.
• Sie müssen die entsprechende Workload für jede .NET SDK-Version installieren, die Sie verwenden möchten.

Die folgende Liste zeigt, welche Workload für jedes .NET SDK installiert werden soll, abhängig von den Apps, auf die Sie abzielen möchten. Obwohl mehrere Zeilen denselben Workloadnamen enthalten können, unterscheiden sich die Workloads immer geringfügig für jedes bestimmte .NET SDK.

• Verwenden des .NET 10 SDK
  • Für das Festlegen von Zielen in .NET 10 ist wasm-tools erforderlich.
  • Zum Targeting von .NET 9 ist wasm-tools-net9 erforderlich.
  • Um .NET 8 zu targeten, ist wasm-tools-net8 erforderlich.
• Verwenden des .NET 9 SDK
  • Zum Targeting von .NET 9 ist wasm-tools erforderlich.
  • Um .NET 8 zu targeten, ist wasm-tools-net8 erforderlich.
• Für das Targeting von .NET 8 ist das .NET 8 SDK erforderlich: wasm-tools.

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 <RunAOTCompilation>-App die auf true festgelegte Eigenschaft Blazor WebAssembly 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. Blazor WebAssembly Apps, die die CPU stark beanspruchen, 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 entfernt verwaltete DLLs nicht, wenn die App veröffentlicht wird. Blazor benötigt die DLLs für Reflection-Metadaten und zur Unterstützung bestimmter .NET-Laufzeitfunktionen. 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 -Ziele finden Sie unter WasmApp.Common.targets (dotnet/runtime GitHub-Repository). Die offizielle Dokumentation zu MSBuild-Eigenschaften ist für das Dokument zu Blazor-MSBuild-Konfigurationsoptionen (dotnet/docs #27395) geplant.

Leistung

Anleitungen zur Leistung finden Sie unter ASP.NET Core-LaufzeitleistungBlazor WebAssembly:

• Heapgröße für einige Browser auf mobilen Geräten
• Neuverknüpfung der Runtime
• SIMD (Single Instruction Multiple Data)
• .NET IL nach der Ahead-of-Time-Kompilierung (AOT) trimmen (.NET 8 oder höher)

Ausnahmebehandlung

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

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

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Konfigurieren und Hosten von .NET WebAssembly-Anwendungen: EH – Ausnahmebehandlung
• Ausnahmebehandlung

Zusätzliche Ressourcen

• ASP.NET Core-Laufzeitleistung Blazor WebAssembly
• ASP.NET Core Blazor WebAssembly native Abhängigkeiten
• Webcil-Verpackungsformat für .NET-Assemblies