Build 2018: .NET Core 2.1 Release Candidate bereit für den Produktiveinsatz
Auf der Build-2018-Konferenz hat Microsoft den Release-Candidate-Status von Version 2.1 von .NET Core, ASP.NET Core und Entity Framework Core bekannt gegeben. Eine Go-Live-Lizenz erlaubt bereits jetzt den Einsatz in der Produktion.
- Dr. Holger Schwichtenberg
Version 2.1 von Microsofts .NET-Core-Produkten biegt auf die Zielgerade ein: Auf der Konferenz Build 2018 gab der Hersteller bekannt, dass .NET Core, ASP.NET Core und Entity Framework Core in der Version 2.1 als Release Candidate bereitstehen und mit einer Go-Live-Lizenz ausgestattet sind, was den produktiven Einsatz erlaubt.
Nach dem im Jahr 2017 veröffentlichten Plan sollte die Version 2.1 schon im ersten Quartal 2018 erscheinen. Dies hat Microsoft dann aber im Februar 2018 auf das zweite Quartal verschoben Eine erste Preview-Version gab es Ende Februar, eine zweite am 10. April 2018. Die NuGet-Pakete für den Release Candidate sind schon seit dem Vorabend der Build-Keynote verfügbar. Die offizielle Downloadseite war vorab nicht aktualisiert, mittlerweile findet sich aber auch dort die neue Version.
Die jetzt mit der Release-Candidate-Version herausgegebene Go-Live-Lizenz erlaubt den Nutzern, das Produkt bereits produktiv in der Softwareentwicklung einzusetzen. Allerdings zeigte die Vergangenheit, dass dies in der neuen Microsoft-Ära nicht mehr wie bisher bedeutet, dass die Entwickler vor Änderungen an den APIs geschützt sind. Bei der Umstellung auf die RTM-Versionen können also noch Codeänderungen notwendig sein.
Lückenschluss in Entity Framework Core
Die Version 2.1 bringt vor allem für Entity Framework Core und ASP.NET Core umfangreiche Neuerungen. Bei Entity Framework Core schließt Microsoft vier gravierende Schwächen, die die neu implementierte Core-Variante gegenüber dem klassische ADO.NET Entity Framework hatte. Zum einen werden Gruppierungen nun tatsächlich zur Datenbank gesendet und nicht mehr im RAM ausgeführt, was gerade bei großen Datenmengen zu einer absolut inakzeptablen Ausführungsgeschwindigkeit führte.
Zweitens bietet Entity Framework Core nun auch das aus dem Vorgänger bekannte automatische Lazy Loading verbundener Datensätze wieder an. Es ist aber nicht mehr wie im Vorgänger standardmäßig aktiv, sondern der Entwickler muss es explizit einschalten, um das unbewusste Nachladen von Daten in Schleifen zu verhindern. Dabei kann man zwischen Lazy Loading mit automatisch generierten Runtime Proxies oder einer vom ORM-Mapper unterstützten Variante mit eigenen Ergänzungen der Entitätsklasse wählen.
Als dritten Punkt baut Microsoft auch die bisher fehlende Unterstützung für ambiente Transactions mit System.Transactions.TransactionScope in Entity Framework Core ein. Zu guter Letzt ist es wieder möglich, auch Resultsets auf Nicht-Entitätstypen abzubilden. Damit können Entwickler dann Datenbank-Views, Tabellen ohne Primärschlüssel und Ergebnisse von SQL-Befehlen, Stored Procedures und Table Value Functions abbilden, auch wenn deren Resultset nicht der Struktur einer bestehenden Tabelle entspricht.
Darüber hinaus bekommt Entity Framework Core auch ganz neue Funktionen: Die neu eingeführten Value Converter erlauben Wertkonvertierung beim Materialisieren und Speichern von Objekten. Der im Februar angekündigte Cosmos-DB-Treiber für Entity Framework Core ist aber noch nicht reif für den Einsatz, wie sich auf GitHub nachlesen lässt.
Mehr Kapselung in ASP.NET Core 2.1
Beim Anlegen eines neuen Webprojekts mit ASP.NET 2.1 in Visual Studio 2017 (Version 15.7) oder dem Kommandozeilenwerkzeug dotnet new fällt sofort auf, dass viel weniger Webseiten als bisher angelegt werden: Alle Seiten für die Benutzeranmeldung und Benutzerverwaltung fehlen. Dennoch ist beim Start der Anwendung diese Funktion vorhanden. Microsoft hat diese Funktionen in die DLL (Microsoft.AspNetCore.Identity.UI.dll) gekapselt.
Im generierten Programmcode findet man lediglich unter /Area/Identity/Pages/_ViewStart.cshtml eine Konfiguration dazu, welche Layoutseite als Master Page zum Einsatz kommen soll. Entwickler, denen die Anpassungsfähigkeiten über die Layoutseite nicht reichen, können sich dann aber die einzelnen Webseiten herausgenerieren lassen (per Funktion in Visual Studio: Add Scaffold/Identity) und sie manuell wie bisher bearbeiten. Zu beachten ist aber, dass die generierten Seiten dann immer das Model der sogenannten Razor Pages nutzen, auch wenn man ein Projekt mit dem Model-View-Controller-Framework angelegt hatte. Razor Pages wurden in ASP.NET Core 2.0 eingeführt und sind das neue von Microsoft favorisierte Entwicklungsmodell für Server Side Rendering.
Mit Areas können Entwickler innerhalb eines Projekts die Seiten organisatorisch trennen. Jede Area kann ihr eigenes /Shared-Verzeichnis besitzen. Microsoft vereinfacht die Datenbindung in Razor Pages, indem die Annotation BindPropertyAttribute zentral auf eine Page-Model-Klasse anwendbar ist. Mit der Schnittstelle IPageFilter können Entwickler eigene Logik nun vor und nach dem Razor Page Handler ausführen.
Für auf ASP.NET Core basierende Web-APIs bietet Microsoft mit der Controller-Annotation ApiController8 mehr Automatismen für Parameterbindung und -Validierung. So sucht ASP.NET Core komplexe Typen wieder standardmäßig im Inhalt der HTTP-Nachricht statt im Query String. Wenn Validierungen fehlschlagen und dadurch der Model State ungültig ist, liefert die Web-API nun automatisch den Fehler 400 (Bad Request) zurück.
Die neue Klasse ActionResult<T> erlaubt das individuelle Setzen von HTTP-Statuscodes und gleichzeitig die Rückgabe eines typisierten Objekts für den Inhalt der Antwort. Damit wird die Generierung von Swagger-OpenAPI-Dokumentationen vereinfacht. Beim untypisierten IActionResult musste der Entwickler bisher Swagger per zusätzlicher Annotation über den Ergebnistyp informieren. Zudem unterstützt Microsoft nun die Übermittlung von Problemdetails nach RFC 7808.
Neu in ASP.NET Core 2.1 ist auch, dass ein performanteres Hosting direkt im Prozess des Microsoft-Webservers Internet Information Services (IIS) möglich ist. In den bisherigen Versionen lief ASP.NET Core immer in einem eigenen Prozess (Kestrel oder Web Listener alias http.sys).
Während auch die Portierung von SignalR, Microsofts Framework für bidirektionale Kommunikation zwischen Webserver und Browser, den Release-Candidate-Status erreicht hat, verbleibt die WebHooks-Bibliothek im Preview-Status. Microsoft begründet dies auf Github damit, dass die Funktionalität noch nicht ausreichend sei, weil man sich mit den WebHooks im Rahmen von ASP.NET Core 2.1 nicht genug beschäftigt habe.
Schnellere Übersetzung in .NET Core 2.1
Das Basis-Framework .NET Core profitiert in Version 2.1 funktional nicht so stark wie ASP.NET Core und Entity Framework Core. Microsoft hat hier vor allem an der Geschwindigkeit des Übersetzungsprozesses und der HTTP-Implementierung in der Klasse HttpClient gearbeitet. Das Kommandozeilenwerkzeug bietet nun auch globale Werkzeuge, wie es bereits aus Node.js und npm bekennt ist. Global installierte Werkzeuge (dotnet tool install -g abc) können Entwickler jetzt nicht nur über dotnet abc, sondern auch über die Eingabe abc direkt aufrufen.
(Bild: Microsoft )
Die umfangreichste Verbesserung in .NET Core 2.1 ist die Verfügbarkeit des Windows Compatibility Pack for .NET Core, das viele Klassen aus dem alten .NET Framework 4.x in die .NET-Core-Welt portiert. Dazu gehören zum Beispiel Klassen für den Registry-Zugriff, Datenbankzugriffe per ODBC, LINQ für DataSets, das Code Document Object Model (CodeDOM), Zugriff auf serielle Ports und LDAP-Server wie das Active Directory sowie die sehr umfangreiche Windows Management Instrumentation (WMI), mit der man Informationen aus dem Betriebssystem auslesen und verändern kann. Zu beachten ist aber, dass einige dieser Bibliotheken auf Windows laufen und daher nur dann eingesetzt werden können, wenn .NET Core nicht plattformneutral sein muss, sondern der ausschließliche Betrieb auf Windows benötigt wird. (bbo)
