.NET 8.0: Blazor erobert in der vierten Preview den Server

Microsoft baut in .NET 8.0 Preview 4 das SPA-Framework Blazor für das alternative Server-Side-Rendering aus und verbessert die Ausgaben von MSBuild.

In Pocket speichern vorlesen Druckansicht 2 Kommentare lesen

(Bild: Shutterstock)

Lesezeit: 6 Min.
Von
  • Dr. Holger Schwichtenberg
Inhaltsverzeichnis

Die vierte Vorschauversion für .NET 8.0 ist erschienen. Microsoft liefert damit im .NET 8.0 SDK einige deutliche Verbesserungen der Konsolenausgaben des Übersetzungswerkzeugs MSBuild. In Verbindung mit dem modernen Windows Terminal sind die Ausgaben nun besser strukturiert. Target Framework und Übersetzungsergebnis werden in Cyan, Grün und Rot farblich hervorgehoben. Bei jedem Schritt sieht man die aktuelle Dauer in Sekunden (Abb. 1).

Dazu ist beim Übersetzen mit dotnet build zusätzlich der Parameter /tl (die Buchstaben stehen für Terminal Logger) anzugeben. Die Option prüft automatisch, ob das verwendete Konsolenfenster die neuen Features unterstützt und fällt ansonsten auf den alten Console Logger zurück. Entwicklerinnen und Entwickler können aber mit /tl on beziehungsweise /tl off auch die Verwendung des neuen beziehungsweise alten Ausgabemodus erzwingen.

Verbesserte Terminal-Ausgaben in MSBuild (Abbildung 1).

(Bild: Microsoft)

Für das in Preview 3 eingeführte neue, aber optionale Ausgabeverzeichnis .artifacts hat Microsoft eine Änderung implementiert: Es heißt jetzt im Standard artifacts ohne Punkt, da Microsoft zu der Erkenntnis gelangt ist, dass in den meisten .gitignore-Dateien für .NET "artifacts" schon ausgeschlossen ist. Die Aktivierung des neuen Ausgabeverzeichnisses kann nun nicht mehr in einer Projektdatei erfolgen, sondern nur noch in einer Datei Directory.Build.props:

<Project>
  <!-- See https://aka.ms/dotnet/msbuild/customize for more details on customizing your build -->
  <PropertyGroup>
   <ArtifactsPath>$(MSBuildThisFileDirectory)artifacts</ArtifactsPath>
   </PropertyGroup>
</Project>

Bei der Paketverwaltung können die Befehle dotnet add package und dotnet restore nun Sicherheitswarnungen ausgeben (Abb. 2), wenn der Entwickler oder die Entwicklerin mit der Projekteinstellung <NuGetAudit>true</NuGetAudit> einwilligt. Auch ist wählbar, ab welchem Schweregrad man Meldungen erhält, etwa

<NuGetAuditLevel>moderate</NuGetAuditLevel>

Die Level sind low, moderate, high und critical.

Sicherheitswarnungen bei Lücken in NuGet-Paketen (Abb. 2).

In der Klassenbibliothek gibt es nun mit der abstrakten Klasse TimeProvider eine einfache Möglichkeit, Zeitangaben inklusive Zeitzone im Rahmen von Tests beliebig vorzutäuschen. Auch die Zeitangaben in Task.Delay() and Task.Async() können darauf zurückgreifen.

Für die Ahead-of-Time-Kompilierung bietet Microsoft nun mit

dotnet new console --aot

an, ein Konsolenprojekt mit AOT-Unterstützung anzulegen.

Für das in Preview 3 eingeführte Server Side Rendering (SSR) von Razor Components im Blazor-Stil gibt es nun auch eine Streaming-Option. Ein kleines JavaScript-Skript sorgt dafür, dass der Client bereits Inhalte (zum Beispiel eine Ladeanimation) erhält, bevor asynchrone Aufgaben auf dem Server erledigt sind. Nach Fertigstellung der asynchronen Aufgaben wird das DOM auf dem Client per JavaScript automatisch geändert.

Blazor SSR kann nun auch Formulareinsendungen behandeln. Dazu ist es nötig, in die Seite einen FormDataProvider zu injizieren:

@inject FormDataProvider FormData 

um dann per

FormData.Entries.TryGetValue("Name", out var nameValues)

auf Einträge zugreifen zu können.

Das in .NET 8.0 Preview 1 eingeführte WebCIL-Format, das ein Blockieren von .NET-Kompilaten durch Firewalls und Anti-Viren-Software verhindern soll, funktioniert nun auch für Blazor WebAssembly. Zuvor war das nur mit .NET-erstellten WebAssembly-Modulen möglich, die nicht Blazor zum Rendering verwenden.

Bei den ASP.NET Core Minimal WebAPIs lässt sich nun beim Einsatz der Schnittstellen IFormCollection, IFormFile und IFormFileCollection auf den Zusatz [FromForm] verzichten.

Auch bei dem in Preview 3 eingeführten, für die Ahead-of-Time-Kompilierung notwendigen Request Delegate Generator (RDG) gibt es nun eine Protokollierung, wenn eine Parameterbindung bei einer WebAPI-Operation misslingt.

Entwicklerinnen und Entwickler, die den AOT-Compiler für ein ASP.NET-Core-Projekt aktivieren, erhalten nun Warnungen, falls sie Methoden aufrufen, die nicht kompatibel mit dem AOT-Compiler sind (Abb. 3).

Warnung, dass der Aufruf AddControllers() zum Aktivieren des Model-View-Controller-Frameworks nicht beim Ahead-of-Timer-Compiler möglich ist (Abbildung 3).

(Bild: Microsoft)

Microsoft ist es gelungen, die Dateigröße des AOT-Kompilats für ein einfaches WebAPI-Projekt von 11,3 MB in Preview 3 auf 9,3 MB in Preview 4 zu reduzieren (Abb. 4). Ab Preview 4 sind auch Worker Services in ASP.NET Core mit AOT-Kompilierung möglich. Dafür legt man ein Projekt so an:

Dateigrößen für ein WebAPI-Projekt mit Just-in-Time-Compiler und Self-Contained-Deployment im Vergleich zum AOT-Compiler in Preview 3 und 4 (Abbildung 4).

(Bild: Microsoft)

Die Identitätsverwaltung ASP.NET Core Identity bietet nun neben der HTML-Benutzeroberfläche auch zwei WebAPI-Endpunkte /register und /login an, wenn Entwickler MapIdentityApi<TUser>() aufrufen. Damit lässt sich ASP.NET Core Identity nun auch in Single-Page-Web-Apps verwenden, die mit JavaScript oder Blazor erstellt wurden. In kommenden Previews sollen weitere Funktionen wie Zwei-Faktor-Authentifizierung und E-Mail-Verifikation per WebAPI folgen. Weitere Pläne dazu sind auf GitHub zu finden.

Entity Framework Core hatte bisher eine Herausforderung in der Übersetzung von LINQ-Abfragen mit Mengen elementarer Datentypen in der Bedingung, wie zum Beispiel

var names = new[] { "Blog1", "Blog2" };

var blogs = await context.Blogs
    .Where(b => names.Contains(b.Name))
    .ToArrayAsync();

Da in SQL eine Parametrisierung nach IN nicht möglich ist, verwendete Entity Framework Core bisher ein Inlining der Werte der Variablen:

SELECT [b].[Id], [b].[Name]
FROM [Blogs] AS [b]
WHERE [b].[Name] IN (N'Blog1', N'Blog2')

Durch die fehlende Parametrisierung konnten die Datenbankmanagementsysteme die Abfrage jedoch nicht effizient in ihrem Query Cache verwalten. Entity Framework Core 8.0 verwendet nun die SQL-Funktion OpenJson() an dieser Stelle:

Executed DbCommand (49ms) [Parameters=[@__names_0='["Blog1","Blog2"]' (Size = 4000)], CommandType='Text', CommandTimeout='30']

SELECT [b].[Id], [b].[Name]
FROM [Blogs] AS [b]
WHERE EXISTS (
    SELECT 1
    FROM OpenJson(@__names_0) AS [n]
    WHERE [n].[value] = [b].[Name])

Mit dieser Implementierung wird es auch möglich, Properties, die Mengen elementarer Typen darstellen, wie etwa die Property Tags vom Typ String-Array in dieser Klasse

public class Blog
{
    public int Id { get; set; }
    // ...
    public string[] Tags { get; set; }
}

auf Datenbanktabellen abzubilden. Für die Property Tags entsteht eine Spalte vom Typ nvarchar(max), die dann die Elemente der String-Menge als JSON-Array abspeichert.

Diese neuen Funktionen sind bereits für SQLite- und SQL-Server-Datenbanken realisiert. PostgreSQL soll folgen.

Entity Framework Core 8.0 läuft derzeit auf .NET 6.0, .NET 7.0 und .NET 8.0. Microsoft sagt allerdings im Blogeintrag, dass die fertige Version wahrscheinlich nur für .NET 8.0 freigegeben wird.

.NET 8.0 Preview 4 lässt sich von der Downloadseite herunterladen. Parallel hat Microsoft bei Visual Studio 2022 einen Versionswechsel vollzogen: Version 17.6 ist nun die aktuelle stabile Version und 17.7 die neue Vorschauversion (Abb. 5).

Versionswechsel bei Visual Studio 2022 (Abbildung 5).

Weitere Informationen zu den Neuerungen in .NET 8.0 Preview 4 sind auf Microsofts Entwicklerblog zu finden.

(mai)