.NET 7.0 Preview 4: Die Rückkehr von Program.Main()

In .NET 7.0 kehrt der klassische Startcode vieler Anwendungsarten mit einer Program-Klasse inklusive Main()-Methode in den Projektvorlagen zurück.

In Pocket speichern vorlesen Druckansicht 1 Kommentar lesen

(Bild: VDB Photos/Shutterstock.com)

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

Bei dem im November 2021 erschienenen .NET 6.0 war eines der Ziele von Microsoft, das Programmiermodell für Neueinsteiger möglichst einfach erscheinen zu lassen. Dazu wurde der Startcode von Webanwendungen, Webservices und Konsolenanwendung eingedampft, bei Konsolenanwendungen auf eine einzige Zeile. Dies gefiel nicht allen Entwicklerinnen und Entwicklern; mit der gestern erschienenen .NET 7.0 Preview 4 kommen nun diejenigen zu ihrem Recht, die lieber eine Klassendefinition und explizite Startmethode mit args-Parameter sehen möchten. In der .NET 7.0 CLI (dotnet.exe) gibt es nun beim Anlegen von Projekten die neue Option: --use-program-main.

dotnet new web --use-program-main

In der zeitgleich erschienenen Visual Studio 2022 17.3 Preview 1 heißt die Option im Projektanlegen-Assistenten andersherum ausgedrückt "Do not use top-level statements":

Option "Do not use top-level statements" beim Anlegen von Projekten in Visual Studio 2022 17.3 Preview 1 (Abb. 1).

Zu den Highlights in der vierten Preview von .NET 7.0 gehört der Leistungszuwachs beim Durchsatz von HTTP/2-Anfragen im Webserver Kestrel. Abbildung 2 zeigt von Microsoft veröffentlichte Messergebnisse am Beispiel von gRPC Streaming. Erreicht wurde die Leistungssteigerung, indem eine Thread-sichere Warteschlange mit System.Threading.Channels (seit .NET Core 2.1 verfügbar) zum Einsatz kommt statt der bisher verwendeten Regelung des geteilten Zugriffs auf die TCP-Verbindung mit dem C# Schlüsselwort lock.

Starke Beschleunigung der HTTP/2-Verarbeitung in .NET 7.0 Preview 4 (Abb. 2).

(Bild: Microsoft )

Mit der neuen Rate Limiting Middleware (System.Threading.RateLimiting) können Entwickler die Anzahl der eingehenden HTTP-Anfragen innerhalb von ASP.NET Core beschränken.

Bei den in .NET 6.0 eingeführten minimalen APIs hat Microsoft das Testen verbessert, indem die bisher privaten Typen, die IResult implementieren, nun öffentlich sind. Zusätzlich gibt es typisierte Ergebnisse in der Klasse Microsoft.AspNetCore.Http.TypedResults. Diese Web-API-Operation

public static async Task<IResult> GetForecasts()
{
 return TypedResults.Ok(BL.GetForecastSet());
}

können Entwickler nun testen, mit Rückgabetypprüfung:

// Act
var result = await WeatherAPI.GetForecasts();
 
// Assert mit Typprüfung
Assert.IsType<Ok<WeatherForecast[]>>(result);

Mit dem neuen Union Type Results<TResult1, TResult2, TResultN> kann eine einzelne Web-API-Operation deklarieren, dass sie verschiedene Typen zurückliefert. Diese Information wird in der Open-API-Spezifikation (Swagger) entsprechend berücksichtigt.

public static async Task<Results<Ok<WeatherForecast[]>, NotFound, ForbidHttpResult>> GetForecasts(int id)
{
 
	try
	{
		if (id > 0) return TypedResults.Ok(BL.GetForecastSet(id));
		return TypedResults.Forbid();
	}
	catch (Exception ex)
	{
		return TypedResults.NotFound();
	}
 
}

Für das Bereitstellen einer Open-API-Spezifikation für eine minimale Web-API können Entwicklerinnen nun das neue Paket Microsoft.AspNetCore.OpenApi hinzubinden und mit .WithOpenApi() für eine Operation aktivieren. Das neue Paket wird automatisch eingebunden, wenn beim Anlegen eines Projekts --enable-openapi (bei der .NET CLI) bzw. "Enable OpenAPI support" (in Visual Studio) gewählt wird.

Bei ASP.NET Core SignalR kann ein Server nun beim Aufruf einer Methode auf dem Client darauf warten, dass dieser eine Antwort liefert. Das funktioniert aber noch nicht mit dem Cloud-Dienst Azure SignalR Service.

In der .NET-Klassenbibliothek ist die in .NET 7.0 Preview 1 begonnene Annotierung der Klassen im Namensraum Microsoft.Extensions für Nullable Reference Types nun abgeschlossen. Die wesentlichen Arbeiten kamen dabei nicht von Microsoft selbst, sondern dem externen ukrainischen Entwickler Maksym Koshovyi.

Der im Namensraum Microsoft.Extensions.Caching.Memory implementierte Zwischenspeicher liefert nun die Metriken CurrentEntryCount, CurrentEstimatedSize, TotalHits und TotalMisses, die Entwickler mit der neuen Methode GetCurrentStatistics() geliefert bekommen.

Im Namensraum System.Formats.Tar gibt es nun Klassen für das Archivformat TAR, z.B.

System.Formats.Tar.TarFile.CreateFromDirectory(@"T:\Dokumente", @"t:\Dokumente.tar", true);

Ebenso gibt es TAR-APIs für das Hinzufügen von Dateien zu Archiven, das Entpacken eines ganzen Archivs und einzelner Dateien. Es gibt bisher allerdings nur synchrone Methoden; asynchrone Implementierungen sollen später folgen.

Die Klassen DateTime, TimeStamp, DateTimeOffset und TimeOnly sollen nun auch die Eigenschaften Microseconds und Nanoseconds bieten. Bisher gab es als kleinste Einheit nur Tick, was in .NET 100 Nanosekunden entspricht. Allerdings konnte der C# 11-Compiler in ersten Experimenten mit .NET 7.0 Preview 4 die neuen, in einem Blogeintrag erwähnten Eigenschaften nicht finden.

var startZeitunkt = DateTime.Now;
// …
var endeZeitunkt = DateTime.Now;
TimeSpan differenz = endeZeitunkt - startZeitunkt;
Console.WriteLine(differenz.TotalMilliseconds + "ms");
Console.WriteLine(differenz.TotalMicroseconds + "µs"); 
Console.WriteLine(differenz.TotalNanoseconds + "ns"); 

Beim Objekt-Relationalen Mapper Entity Framework Core gibt es in Version 7.0 Preview 4 nur kleine Verbesserungen für die Wertkonverter. Diese kann man nun auch für datenbankseitig automatisch generierte Primärschlüssel verwenden, wenn im Programmcode die Schlüssel im Sinne des Domain-driven Design (DDD) als eigenständiges Wertobjekt deklariert sind.

Die fünfte Preview-Version ist schon in zwei Wochen im Rahmen der BUILD-Konferenz 2022 zu erwarten, die vom 24. bis 26. Mai 2022 als Online-Konferenz stattfinden wird. Die fertige Version von .NET 7.0 ist für den November 2022 angekündigt und soll Support bis Mai 2024 bekommen.

(map)