Sie sind hier

.NET 9.0 (.NET 9)

Eintrag zuletzt aktualisiert am: 10.09.2024
 Fachbücher zum Thema .NET 9.0 (.NET 9)

.NET 9.0 ist der Nachfolger von .NET 8.0, der im November 2024 erscheinen soll.

Fakten zu .NET 8.0

Versionsgeschichte inkl. Vorabversionen

  • Preview 1 am 13.2.2024
  • Preview 2 am 12.3.2024
  • Preview 3 am 11.4.2024
  • Preview 4 am 21.5.2024
  • Preview 5 am 21.5.2024
  • Preview 6 am 09.07.2024
  • Preview 7 am 13.08.2024
  • Release Candidate 1 am 10.09.2024

Geplante Versionen

Release Candidate 2 --> Oktober 2024
RTM --> 12. November 2024

Neuerungen in der .NET Runtime

Dass .NET beim Behandeln von Laufzeitfehlern langsam ist, ist seit vielen Jahren bekannt. Daher gehört die Vermeidung von Laufzeitfehlern zu den Best Practices. Insbesondere sollte man Laufzeitfehler nicht als Ersatz für Kontrollflussanweisungen verwenden, etwa um bei ungültigen Werten eine Schleife oder Unterroutine zu verlassen. Microsoft hat aber laut eigener Aussage in den Release Notes zur .NET Runtime die Behandlung von Laufzeitfehlern um den Faktor zwei bis vier gesteigert. Das gilt für Windows x64, Windows ARM64, Linux x64 und Linux ARM64, aber nicht für 32-Bit-Windows. Entwicklerinnen und Entwickler können via Umgebungsvariable
DOTNET_LegacyExceptionHandling = 1
oder Projektdateieinstellung
<RuntimeHostConfigurationOption Include="System.Runtime.LegacyExceptionHandling" Value="true" />
die Laufzeitumgebung dazu zwingen, das alte, langsamere Fehlerbehandlungsverfahren einzusetzen.

Neuerungen im .NET SDK in .NET 9.0 (Auswahl)

Das Kommandozeilenwerkzeug dotnet test konnte bisher schon automatisierte Tests für ein Projekt mit mehreren .NET-Versionen nacheinander ausführen. Neu in .NET 9.0 Preview 2 ist, dass dies parallel passiert. Zudem verwendet dotnet test den in .NET 8.0 eingeführten, übersichtlicheren Terminal Logger https://www.heise.de/tests/Microsofts-NET-8-0-im-Test-Grosse-Innovationen-beim-Webframework-Blazor-9567319.html?seite=7, was sich insbesondere positiv auf die Darstellung der Testergebnisse während und nach der Testausführung auswirkt.

Bei .NET SDK-basierten Werkzeugen haben Entwicklerinnen und Entwickler nun die Möglichkeit, mit der Option --allow-roll-forward das Werkzeug auf einer neueren .NET-Hauptversion laufen zu lassen, wenn die .NET-Laufzeitumgebung, für die das Werkzeug kompiliert wurde, nicht verfügbar ist. Diese neue Option kann sowohl bei dotnet tool install als auch dotnet tool run verwendet werden. Es gibt freilich keine aufgrund der Breaking Changes zwischen .NET-Hauptversionen keine Garantie, dass das Werkzeug auf einer neueren .NET-Laufzeitumgebung funktioniert.

Der in .NET 8.0 eingeführte, prägnantere Terminal Logger (zum Beispiel bei dotnet build /tl und msbuild /tl) zeigt nun Fehlermeldungen mit Zeilenumbrüchen besser an und zudem am Ende seiner Ausgabe eine Zusammenfassung der Anzahl der Fehler und Warnungen. Was nicht in der Dokumentation steht, aber aus den Screenshots von Microsoft (siehe Abbildungen 2 und 3) hervorgeht und sich im Schnelltest bestätigte: Bei dotnet build kann man nun auf den Parameter /tl beziehunsgweise -tl verzichten, um den Terminal Logger zu aktivieren. Bei MSBuild ist aber ohne diesen Parameter auch im .NET 9.0 SDK weiterhin der klassische Logger aktiv.

Neuerungen bei den .NET-Basisklassen (Auswahl)

In der Basisklassenbibliothek gibt es neuen LINQ-Operatoren CountBy() und AggregateBy(). Eine neue Remove()-Methode in der in .NET 6.0 eingeführten Mengenklasse PriorityQueue entfernt Elemente, auch wenn diese nicht an der Reihe sind. Beim Debugging von Dictionary-Klassen zeigen die Debugger nun die Inhalte deutlich übersichtlicher an.

Bei den kryptographischen Funktionen liefert Microsoft ab .NET 9.0 eine Implementierung des KECCAK Message Authentication Code (KMAC) des US-amerikanischen National Institute of Standards and Technology (NIST) https://csrc.nist.gov/pubs/sp/800/185/final.

.NET 9.0 erlaubt nun auch wieder das Persistieren zur Laufzeit erzeugter Assemblies im Dateisystem mit der Methode Save() in der Klasse PersistedAssemblyBuilder. Diese Möglichkeit gab es schon im Klassen .NET Framework in AssembyBuilder (vgl. Dokumentation zu Save() https://learn.microsoft.com/en-us/dotnet/api/system.reflection.emit.assemblybuilder.save). Im modernen .NET konnte man bisher zur Laufzeit erzeugte Assemblies nur im RAM halten.

Bei der Datenstruktur System.TimeSpan, die es seit der ersten Version des .NET Framework aus dem Jahr 2002 gibt, war bisher eine Herausforderung, dass die Konvertierungsmethoden FromMicroseconds(), FromSeconds(), FromMinutes(), FromHours() und FromDays() als Parameter einen double-Wert erwarteten. Der double-Typ ist als Fließkommazahl aber ungenau. Microsoft führt daher in .NET 9.0 zusätzlich neue Varianten der From-Methoden ein, die Ganzzahlen als Parameter erhalten, z.B.
  • public static FromDays(int days, int hours = 0, long minutes = 0, long seconds = 0, long milliseconds = 0, long microseconds = 0)
  • public static TimeSpan FromHours(int hours, long minutes = 0, long seconds = 0, long milliseconds = 0, long microseconds = 0);
  • public static TimeSpan FromMilliseconds(long milliseconds, long microseconds = 0);

Neuerungen bei System.Text.Json

Die neuste Version der JSON-Bibliothek System.Text.Json erlaubt die Anpassung der Einrückung in den JsonSerializerOptions. Dazu gibt es dort neue Einstellungen IndentCharacter und IndentSize. Mit JsonSerializerOptions.Web können Entwicklerinnen und Entwickler nun auf einfache Weise dieselben Einstellungen für die JSON-Serialisierung und -Deserialisierung wählen, die in ASP.NET Core WebAPI voreingestellt ist.

AllowOutOfOrderMetadataProperties in System.Text.Json: siehe https://github.com/dotnet/runtime/pull/97474