© Sylverarts Vectors/shutterstock.com, © S&S Media
Vor allem Bugfixes - und wieder Breaking Changes

.NET Core 3.1 ist reif


.NET Core 3.1 ist am 3. Dezember 2019 erschienen. Ungewöhnlich ist: Es gibt nur sehr wenige neue Funktionen, sondern vor allem Fehlerbehebungen und sogar inkompatible Änderungen, die es bei einer Version mit Änderung der Versionsnummer an der zweiten Stelle gar nicht geben dürfte.

.NET Core 3.0 einschließlich Entity Framework Core 3.0 und ASP.NET Core 3.0 sind am 23. September 2019 erschienen. Wer diese Versionen intensiv in der Praxis einsetzt, wird einige Unzulänglichkeiten bemerkt haben. Man könnte spotten: Dass diese Versionen schon im September erschienen sind, liegt nicht daran, dass sie fertig waren, sondern daran, dass Microsoft im Mai 2019 das Erscheinen für die .NET Conf 2019 am 23. September verkündet hatte.

.NET Core 3.1 mit Entity Framework Core 3.1 und ASP.NET Core 3.1 sollten laut der Ankündigung vom Mai schon im November 2019 erscheinen. Das hat Microsoft dann aber auf Dezember vertagt, was auch gut war.

Bugfixes

Die 3.0er Versionen enthielten eine Reihe von kleinen und größeren Problemen, zum Beispiel bei der Benutzerverwaltung und Authentifizierung in ASP.NET Core Blazor Server. Während man mit Blazor Server eine Single Page Application (SPA) erstellen kann [1], basieren die von Microsoft in ASP.NET Core Identity gelieferten Webseiten zur Benutzerverwaltung und Authentifizierung noch auf ASP.NET Core Razor Pages, also einer klassische Multi Page Application (MPA). Solange man in ASP.NET Core 3.0 diese Webseiten im Standardlayout von Microsoft verwendete, funktionierte die Integration zwischen Razor Pages und Blazor Components gut. Sobald man aber zur Anpassung des Layouts die Razor Pages mit Add/New Scaffolded Item/Identity explizit als Templates in das Projekt hineingenerieren lies, sah man die Menüzeile plötzlich doppelt. Microsoft hatte die Layoutseiten falsch verschachtelt, der Entwickler musste es selbst lösen. In ASP.NET Core 3.1 ist das gelöst.

Einen echten Showstopper gab es in .NET Core 3.0, wenn man eine klassische .NET-Framework-basierte Anwendung (z. B. Windows Forms oder Windows Presentation Foundation), die noch mit typisierten DataSets (.xsd-Dateien) arbeitet, auf .NET Core migrieren wollte. Das war in der Zeit vor Entity Framework (gerade in Windows Forms- und WPF-Anwendungen) üblich und kommt daher auch heute noch in einigen Projekten vor. Typisierte DataSets sollten zwar in .NET Core 3.0 möglich sein, dem Autor dieses Beitrags fiel in einem entsprechenden Projekt aber auf, dass der von den .xsd-Dateien generierte Programmcode zur Laufzeit eine Null Reference Exception auslöst und zwar in der Methode SqlParameterCollection.Add(). Obwohl der Autor das am 2. September 2019 via GitHub gemeldet hatte [2] und ein Microsoft-Entwickler am 14. September 2019 den Fehler behoben hatte, wanderte die Fehlerbehebung nicht mehr in die Version der System.Data.SqlClient.dll, die mit .NET Core 3.0 ausgeliefert wurde. Dabei fielen drei Dinge auf:

  1. Der Microsoft-Entwickler musste zugeben [3], dass es nicht ausreichend Unit-Tests für die System.Data.SqlClient gibt, also nicht gut getestet wurde.

  2. Es hat wohl auch niemand bei Microsoft ein typisiertes DataSet einmal manuell auf .NET Core 3.0 getestet, denn der Fehler trat in jedem typisierten DataSet auf.

  3. Microsoft ist immer noch nicht agil genug, um einen Bugfix, der neun Tage vor dem Release fertig ist, in das Produkt einzubauen, selbst wenn es so ein kritischer Bug ist, der das Funktionieren gänzlich verhindert.

Als Workaround kam übrigens der Vorschlag, doch eine andere Überladung von SqlParameterCollection.Add() zu verwenden. Da aber ja der Aufruf von SqlParameterCollection.Add() im generierten Programmcode lag und dreimal pro Tabelle vorkommt, hätte das einen enormen Aufwand bedeutet, der nach jeder Änderung am DataSet immer wieder neu vollzogen hätte werden müssen. Auch die Anpassung des Codegenerators war keine Option, denn bei typisierten DataSets gab es noch keine Templatesprache wie T4 oder Handlebars, sondern der Codegenerator war noch als reine C#-Klasse mit Namen MSDataSetGenerator implementiert. Die Klasse kann man zwar austauschen, das ist jedoch viel Arbeit.

In diesem Stil gab es noch eine Reihe weiterer Probleme in .NET ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang