.NET 7.0 Release Candidate 2 erscheint mit Multi-Threading für WebAssembly

Microsoft hat den zweiten Release Candidate für.NET 7.0 mit Neuerungen für WebAssembly sowie für das OR-Mapping veröffentlicht. Der Release-Candidate-Phase für das im November 2022 anstehende Major Release gingen bereits sieben Previews voraus, über die heise Developer berichtet hat.

Lesen Sie auch

Einbiegen auf die Zielgerade: .NET 7.0 Release Candidate 1 ist fertig

---

.NET 7 Preview 7: Mehr Eingriffspunkte in den OR-Mapper, aber unvollständig

---

.NET 7 Preview 6: Diese Neuigkeiten gibt es für Webentwickler

---

NET 7.0 Preview 5: JWT-Vereinfachungen und flexibleres Vererbungsmapping

---

Preview-Reihe für .NET 7 startet mit neuen Webfeatures

Mehr anzeigenWeniger anzeigen

.NET-Code in WebAssembly gibt es inzwischen in zwei Formen: Seit Mai 2020 können .NET-Entwickler Blazor-WebAssembly-basierte Single-Page-Web-Apps in modernen Browsern erstellen. Zusätzlich hat Microsoft in .NET 7.0 Release Candidate 1 im September 2022 den Workload "wasm-experimental" eingeführt, um .NET-Code auch unabhängig von dem Blazor-UI-Komponentenmodell im Browser oder einem Node.js-Konsolenprozess zu starten. In beiden Implementierungen waren bisher schon asynchrone Aufrufe mit async/await möglich, beispielsweise von Web-APIs.

Für den zweiten Weg ohne Blazor-UI bietet Microsoft nun auch den Start expliziter Threads in .NET 7.0 Release Candidate 2 an. Das folgende Listing, das aus einem Blogeintrag von Microsoft stammt, zeigt den Start eines solchen expliziten Threads mit der Klasse System.Threading.Thread, die schon seit dem .NET Framework 1.0 aus dem Jahr 2002 in .NET existiert.

using System;
using System.Threading;
using System.Runtime.Versioning;
using System.Runtime.InteropServices.JavaScript;

[assembly:SupportedOSPlatform("browser")]

new Thread(SecondThread).Start();
Console.WriteLine($"Hello, Browser from the main thread {Thread.CurrentThread.ManagedThreadId}");

static void SecondThread()
{
    Console.WriteLine($"Hello from Thread {Thread.CurrentThread.ManagedThreadId}");
    for (int i = 0; i < 5; ++i)
    {
        Console.WriteLine($"Ping {i}");
        Thread.Sleep(1000);
    }
}

Das Multi-Threading-Feature für .NET mit WebAssembly hat vorerst den Status "experimentell". Innerhalb von Blazor-WebAssembly-Anwendungen soll die Unterstützung für Multi-Threading aber erst in .NET 8.0 enthalten sein.

Mehr Infos

Am 22. November 2022 richten heise Developer und dpunkt.verlag in Kooperation mit www.IT-Visions.de mit der betterCode() .NET 7 eine Online-Konferenz zum kommenden Release von Microsofts Entwicklungsplattform .NET aus. Dieses soll im November erscheinen. Es ist zwar kein Long-Term Release wie das letztes Jahr erschienene und gerade aktuelle .NET 6., in das neue Release fließen aber viele Neuerungen und Arbeiten zur Verbesserung der Codequalität ein, die dann die Migration auf .NET 7 rechtfertigen können.

Verbessertes Output Caching

In ASP.NET Core 7.0 Release Candidate 2 hat Microsoft zudem das Output Caching des Webserverframeworks verbessert. Die bisher im JSON-Format abgelegten Cache-Inhalte werden nur binär gespeichert, was die Serialisierung und Deserialisierung beschleunigt sowie die Größe des Zwischenspeichers vermindert.

Zudem verbessert der zweite Release Candidate die Einflussnahme auf die Cache-Regeln. Während bisher das Caching immer pro Domänenname erfolgte, können die Inhalte im Zwischenspeicher nun wahlweise domänenübergreifend gelten:

builder.Services.AddOutputCache(options =>
{
    options.AddBasePolicy(builder => builder.SetVaryByHost(false));
}

Mit einer Instanz der Klasse OutputCachePolicyBuilder können Entwicklerinnen und Entwickler eigene Regeln für das Caching definieren.

Entity Splitting beim OR-Mapping

Bei Entity Framework Core 7.0 hat Microsoft im Release Candidate 2 das Entity Splitting wieder eingeführt, das es schon im klassischen ADO.NET Entity Framework gab, aber in Entity Framework Core in den Versionen 1.0 bis 6.0 nicht unterstützt wurde. Entity Splitting bedeutet, eine .NET-Klasse auf mehrere Datenbanktabellen aufzuteilen (siehe Abbildung). Den Gegensatz, das Table Splitting, das eine Tabelle auf mehrere Klassen aufteilt, gibt es schon seit Entity Framework Core 2.0.

Entity Splitting lässt sich in der Fluent-API der Kontextklasse mit dem Aufruf der Methode SplitToTable() aktivieren. Das folgende Codefragment legt fest, dass aus der Klasse Company die Eigenschaften City, Street, Postcode und Country nicht in die Tabelle "Company", sondern in eine eigene Tabelle "Address" wandern. Dabei erhält die Eigenschaft Street den abweichenden Spaltennamen "Streetname".

   modelBuilder.Entity<Company>(
    entityBuilder =>
    {
     entityBuilder
         .ToTable("Company")
         .SplitToTable(
             "Address",
             tableBuilder =>
             {
              tableBuilder.Property(x => x.City);
              tableBuilder.Property(x => x.Street).HasColumnName("Streetname");
              tableBuilder.Property(x => x.Postcode);
              tableBuilder.Property(x => x.Country);
             });
    });

Beim Forward Engineering legt Entity Framework Core automatisch beide Datenbanktabellen an. In der Tabelle "Address" kommt der gleiche Primärschüssel wie in "Company" zum Einsatz (siehe Abbildung). Unter der Voraussetzung, dass die Primärschlüssel gleich sind, sind auch bestehende Tabellen beim Reverse Engineering verwendbar.

Entity Framework Core kümmert sich beim Persistieren einer Instanz von "Company" automatisch um die Aufteilung auf zwei INSERT-Befehle beziehungsweise Stored-Procedure-Aufrufe. Beim Materialisieren von "Company"-Instanzen sendet Entity Framework Core einen SELECT-Befehl mit JOIN zur Datenbank.

Ansonsten nichts Neues

Der Blogeintrag zu Entity Framework Core 7.0 Release Candidate 2 geht ausführlich auf das JSON-Mapping ein, das es aber schon seit Release Candidate 1 gibt. Auch alle anderen in dem Blogeintrag verlinkten Funktionen wie Table-per-Concrete-Type-Vererbung, T4-Vorlagen, Massenoperationen oder Stored-Procedure-Aufrufe bei SaveChanges() waren bereits vorhanden.

Der Hauptblogeintrag zu .NET 7.0 Release Candidate 2 listet ebenfalls fast nur Funktionen auf, die in acht vorherigen Vorschauversionen (Preview 1 bis 7 und Release Candidate 1) bereits erschienen sind. Neu sind ein Fallback-Schalter für die im Standard nun deaktivierte Reflection-basierte Serialisierung im JSON-Serializer System.Text.Json sowie zwei neue Analyzer, die auf mögliche Fehler bei der Nutzung der Klassen System.IntPtr und System.UIntPtr sowie der generischen Mathematikklassen hinweisen.

Erscheinungstermin 8. November

.NET 7.0 soll am 8. November 2022 erscheinen, wird aber nur einen Short-Term-Support von 18 Monaten erhalten. Die kommende Version mit längerem Support von 36 Monaten wird .NET 8.0 sein, das für den November 2023 geplant ist.

(mai)