.NET 8.0 biegt mit Release Candidate 1 auf die Zielgerade ein
Der erste Release Candidate bringt eine optimierte AoT-Kompilierung für Android und WebAssembly sowie eine universelle Projektvorlage für Blazor im Browser.
(Bild: Shutterstock)
- Dr. Holger Schwichtenberg
In .NET 8.0 Release Candidate 1 – dem ersten von zwei Release Candidates – überarbeitet Microsoft die Ahead-of-Time-Kompilierung für Android und WebAssembly. Daneben stehen ein universelles Projekt-Template für Blazor im Browser sowie schlüssellose Complex Types beim OR-Mappen zur Verfügung.
Neuerungen für Ahead-of-Time-Kompilierung
Der Release Candidate bringt Intermediate Language Stripping für den Ahead-of-Time-Compiler. Das Stripping entfernt in einem zusätzlichen Arbeitsgang nach der Ahead-of-Time-Kompilierung verbliebenen, nicht mehr notwendigen Intermediate Language Code. Das IL Stripping ist als Option verfügbar beim Kompilieren von .NET-Anwendungen für Android
<AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>und browserbasierten .NET-Anwendungen auf Basis von WebAssembly:
<WasmStripILAfterAOT>true</WasmStripILAfterAOT>Laut Aussage von Microsoft auf dem .NET-Blog sollen diese Optionen zu einer Größenersparnis von bis zu 3,5 Prozent bei Android und 4,2 Prozent bei Blazor WebAssembly und WASM-Browser-Anwendungen führen.
Auf den ersten Blick erscheint es unsinnig, dass nach der Ahead-of-Time-Kompilierung überhaupt noch Intermediate-Language-Code existiert. Microsoft erklärt die Hintergründe im Blogeintrag: Die AOT-Compiler für Android und WebAssembly sind keine vollständigen AOT-Compiler. Sie müssen in verschiedenen Szenarien (z. B. Verwendung von .NET-Basisklassen, die dynamische Codegenerierung nutzen) dennoch den Just-in-Time-Compiler (bei Android) und den Interpreter (bei WebAssembly) nutzen.
Die in der .NET-Klassenbibliothek verbreitete Laufzeitcodegenerierung ist auch der Grund, warum der AOT-Compiler für andere Anwendungsarten deutlichen Beschränkungen unterworfen ist (z. B. bei Konsolen- und WebAPI-Anwendungen) oder noch gar nicht funktioniert (z. B. bei Desktopanwendungen). Microsoft verspricht im Blogeintrag: "Vor diesem Hintergrund werden wir kontinuierlich daran arbeiten, Lücken in der kommenden .NET-9-Version zu schließen."
Universelle Projektvorlage für Blazor
In .NET 8.0 Preview 5 hatte Microsoft für Blazor eine neue Projektvorlage "Blazor Web App" eingeführt. Diese Vorlage ist nun in Release Candidate 1 so ausgebaut, dass sie die bisherigen Vorlagen für Webbrowser-Anwendungen "Blazor Server App", "Blazor Server App Empty", "Blazor WebAssembly App" und "Blazor WebAssembly App Empty" vollständig ersetzt. Nicht durch die neue Vorlage abgedeckt werden hingegen Blazor-Hybrid-Anwendungen wie Blazor Desktop und Blazor MAUI.
Die Projektvorlage "Blazor Web App" (siehe Abbildung 1) erzeugt im Standard ein Projekt mit reinem Blazor-Server-Side-Rendering (Aufruf nur von AddRazorComponents() und app.MapRazorComponents<App>() in Program.cs). Im erzeugten Projekt findet man an der Stelle der bisherigen Ordner "Pages" und "Shared" nun den Ast "Components" mit den Unterordnern "Pages" und "Layout".
Wenn Include sample pages (siehe Abbildung 1) nicht gewählt ist, entsteht ein Projekt nur mit einer Inhaltsseite Home.razor (früher: Index.razor). Die in Blazor übliche Rahmenseitenkonstruktion (App.razor, MainLayout.razor, _Imports.razor) ist dennoch enthalten. Die Einstellungen für das Routing (<Found>, <Navigating> und AdditionalAssemblies) findet man nicht mehr in App.razor, sondern sie sind ausgelagert in die Datei Routes.razor. Es gibt nur eine eigenständige CSS-Datei (app.css) sowie eine CSS-Datei zur MainLayout.razor (MainLayout.razor.css).
(Bild: Holger Schwichtenberg)
Mit der Option Include sample pages (siehe vierte Option in Abbildung 1) erhält man als zusätzliche Seite Weather.razor (früher: FeatchData.razor) mit Streaming Rendering (über Streaming Rendering berichtete heise Developer in einem Beitrag zu .NET 8.0 Preview 4). Zudem werden dann eine Navigationsleiste (/Components/Layout/NavMenu.razor) sowie im Ordner /wwwroot/css/ Bootstrap als CSS-Framework und Open Iconic integriert.
Optionale Interaktivität
Mit der Option Use interactive server components (siehe dritte Option in Abbildung 1) aktiviert man das bisherige Blazor Server in dem Projekt. In Program.cs sieht man zusätzlich die Aufrufe AddServerComponents() und AddServerRenderMode(). Im Ordner /Pages ist eine Seite Counter.razor mit einem interaktiven Zähler zu finden.
Analog dazu aktiviert Use interactive WebAssembly components das bisherige Blazor WebAssembly via AddWebAssemblyComponents() und AddWebAssemblyRenderMode(). Wenn man das Häkchen setzt, bekommt die Entwicklerin bzw. der Entwickler aber nicht mehr ein, sondern zwei Projekte. Eins der beiden Projekte bekommt den Namenszusatz ".Client" und enthält die Komponente Counter.razor mit dem in Preview 6 eingeführten Render-Modus für WebAssembly:
@attribute [RenderModeWebAssembly]Zusätzlich gibt es auch noch eine Counter.razor-Datei im Hauptprojekt. Diese war ein Workaround in Preview 7, den Microsoft in Release Candidate 1 leider vergessen hat zu entfernen. Wenn man die @page-Direktive in die Datei Counter.razor im ".Client"-Projekt verschiebt und AddAdditionalAssemblies(typeof(Counter).Assembly) in Program.cs ergänzt, kann man Counter.razor im Hauptprojekt löschen.
Bei Blazor WebAssembly laufen die Razor-Komponenten auf Basis von WebAssembly im Webbrowser. Die im Browser laufenden Komponenten müssen daher in ein getrenntes Projekt separiert werden, damit ausschließlich dieser Programmcode geladen werden muss und nicht auch die Teile, die nur der Server braucht. Blazor WebAssembly ist durch die Notwendigkeit, die .NET Runtime in den Browser zu laden, ohnehin schon deutlich größer als andere WebAssembly-Lösungen. Daher ist jede Optimierung wichtig.
Wenn Entwicklerinnen und Entwickler sowohl Use interactive server components als auch Use interactive WebAssembly components in der Projektvorlage aktivieren, erhalten sie ebenfalls zwei Projekte. Die Komponente Counter.razor ist dann in dem in Preview 7 eingeführten Render-Modus "Auto":
@attribute [RenderModeAuto]Der Auto-Modus sorgt dafür, dass eine Komponente zunächst per Blazor Server gerendert wird und per WebSockets-Verbindung interaktiv ist, damit ein Benutzer nicht lange auf die Darstellung warten muss. Erst dann lädt der Browser im Hintergrund die .NET Runtime und das Kompilat des ".Client"-Projekts. Ein Wechsel von der WebSockets-Verbindung zu Blazor WebAssembly erfolgt aber nicht im laufenden Betrieb, sondern bei der nächsten Aktivierung der Komponente. Die Anwendung als Ganzes muss aber nicht neu gestartet werden.