Unreife Kernlösung: .NET Core 1.0 ist zwar erschienen, aber noch nicht fertig
Holger Schwichtenberg kritisiert die Lücken, die in .NET Core, ASP.NET Core und Entity Framework Core in Version 1.0 klaffen, insbesondere aber das Fehlen eines plattformübergreifenden GUI-Frameworks.
- Dr. Holger Schwichtenberg
.NET Core, ASP.NET Core und Entity Framework sind überarbeitete Neuimplementierungen, die sich nicht nur durch Plattformunabhängigkeit, sondern auch durch Modularität auszeichnen. Entwickler müssen nur noch das referenzieren, was sie wirklich brauchen. Der Entwicklungsprozess fand komplett in der Öffentlichkeit auf GitHub statt. Microsoft hat zahlreiche Code-Beiträge externer Entwickler einfließen lassen und somit ein gutes Open-Source-Projekte vorgelebt. So weit, so gut.
Über zwei Jahre sind vergangen, seit Microsoft seine modulare und plattformunabhängige Core-Variante des .NET Framework angekündigt hat. Der Erscheinungstermin wurde immer wieder verschoben. Wer in den letzten zwei Jahren schon mit .NET Core gearbeitet hat, ist einen harten Weg gegangen, denn Microsoft hat die APIs immer wieder gravierend geändert. Selbst nach der Release-Candidate-Version mit Go-Live-Lizenz im November 2015 wurden weiterhin munter Konzepte und Namen geändert.
Lücken in der RTM-Version
.NET Core für Windows, Linux und OS X inklusive Konsolenanwendungen, Webframework ASP.NET Core und objektrelationalen Mapper Entity Framework Core sind nun in der "Release to Manufactoring"-Version 1.0 erschienen. Aber die Bezeichnung "fertig" kommt einem wirklich nur schwer über die Lippen. So schreibt das Entity-Framework-Team auf GitHub, dass "Critical O/RM Features" und "High Priority Features" in der Version 1.0 fehlen. Bei ASP.NET Core gibt es weder Unterstützung für SignalR noch für Visual Basic. Auch in der Basisklassenbibliothek fehlen viele APIs im Vergleich zu anderen .NET-Varianten wie .NET "Full" Framework, Mono und Xamarin. Warum zum Beispiel bietet die Klasse System-DateTime keine Methode ToLongDateString() mehr? Die Ersparnis von Bytes im Kompilat ist minimal.
Microsoft wollte die .NET API "aufräumen", hat aber nun eingesehen, dass diese übertriebenen Aufräumarbeiten die Migration erschweren. Seit Mai 2016 ist angekündigt, dass die Basisklassen-APIs von .NET Core an die des .NET "Full" Framework angeglichen werden sollen. Aber die .NET Standard Library gibt es noch nicht in .NET Core 1.0, sondern erst in einer nicht näher bezeichneten späteren Version. Auch einige konzeptionelle Problem bleiben in Version 1.0 ungelöst, zum Beispiel dass das Entity Framework für die Entwicklerwerkzeuge eine große Menge von Nuget-Paketen benötigt, die dann aber zur Laufzeit nur Overhead darstellen – Overhead, den Microsoft mit .NET Core aber gerade vermeiden wollte.
Werkzeuge noch Preview
Ein weiterer Makel ist, dass die Kommandozeilen- und Visual-Studio-Werkzeuge in der Preview-Phase verbleiben. Dieses Erlebnis hatten Entwickler 2005 schon einmal mit .NET 3.0, und wir erinnern uns gut, wie hart es damals war, Windows Presentation Foundation, Windows Communication Framework und Windows Workflow Foundation mit diesen halbfertigen Werkzeugen zu verwenden.
Das ständige Hin- und Her bei den APIs hat auch dazu geführt, dass es weder bei den kommerziellen Komponentenanbietern noch in der Open-Source-Welt nennenswerte Erweiterungen für .NET Core gibt, die zum RTM fertig sind. Wer jetzt mit .NET Core startet, ist erst mal auf das beschränkt, was Microsoft liefert.
Und das, was Microsoft liefert, ist nicht einmal gut dokumentiert. Die Dokumentation zu .NET Core findet man nicht wie bisher im Microsoft Developer Network (MSDN), sondern verstreut auf mehreren Websites (etwa hier, hier und hier). Die Dokumentation ist noch relativ spärlich und mit manchen Platzhaltern versehen. Eine Klassenreferenz gibt es nur für die alten .NET-Bibliotheken; alle neuen Namensräume wie Microsoft.AspNetCore, Microsoft.Framework.ConfigurationModel und Microsoft.Extensions.Logging, Microsoft.Framework.Cache und Microsoft.EntityFrameworkCore fehlen. Dabei wäre es gerade hier wichtig gewesen, da die alten Bibliotheken schon an zahlreichen Stelle gut dokumentiert sind. Auch ist die vorhandene Klassenreferenz nicht wie bisher mit Beispielen gespickt.
Kein UI-Framework
Das Hauptproblem von .NET Core ist aber, dass es nicht den aktuellen Hauptbedarf der Microsoft-Kunden trifft, der sich in den Jahren der Entwicklung von .NET Core zunehmend herausgebildet hat. Eine plattformunabhängige Konsolen- oder Webserveranwendung ist eben nicht das vorrangige Problem der Unternehmen, die heute .NET einsetzen; was die Unternehmen wirklich brauchen, ist eine plattformunabhängige Lösung für grafische Benutzeroberflächen.
Hier bietet .NET Core keinerlei Lösung, denn es ist überhaupt kein XAML- oder anderes GUI-Framework enthalten. Es bleibt dabei, dass es XAML in vier nicht ganz kompatiblen Varianten (WPF, Silverlight, Windows Runtime-XAML, Xamarin Forms) gibt, die aber jeweils nur auf bestimmten Geräten laufen.
(Bild: Holger Schwichtenberg)
Auf allen Betriebssystemen gibt es .NET, aber die Codewiederverwendung ist eingeschränkt, da die Benutzeroberflächen pro XAML-Variante erstellt werden müssen. Und es gibt Kunden, die Hunderte Bildschirmmasken in ihren Anwendungen haben.
Auch nach dem Erscheinen von .NET Core ist HTML weiterhin das einzige wirklich plattformunabhängige GUI-Framework, und immer mehr Softwareanbieter sind gezwungen, von .NET und XAML auf JavaScript und HTML zu wechseln, damit die Anwendungen mit einer Codebasis entsprechend dem Kundenbedarf nicht nur auf Windows-, sondern auch auf iOS- und Android-Geräten laufen. Gerne machen viele diesen Wechsel nicht, denn JavaScript und HTML sind nicht nur weit entfernt von der bisherigen Codebasis, sondern auch vom bisherigen Know-how und Wohlgefühl der eigenen Entwickler.
.NET Core ist daher nur ein erster kleiner Schritt. Es fehlt ein plattformunabhängiges GUI-Framework auf Basis von XAML, mit dem sich WPF-Anwendungen mit geringem Aufwand auf andere Plattformen bringen lassen. Microsoft hat spätestens seit der Übernahme von Xamarin alles im Haus, was für ein plattformübergreifendes XAML benötigt wird. Wichtig ist, dass jetzt bald eine Lösung kommt. Leider sieht es danach aber nicht aus. Die im November 2014 angekündigte Modularisierung von WPF, die ein erster Architekturschritt für die Plattformunabhängigkeit gewesen wäre, ist elf Monate später schon wieder abgeblasen.
Nur wenige Gründe für .NET Core
Was spricht also dafür, jetzt schon .NET Core 1.0 einzusetzen? Leider nicht viel. Entity Framework Core 1.0 ist gut für den lokalen Datenzugriff auf Mobilgeräten mit SQLite-Datenbanken. Hier bietet sich die Chance, für Offline-Szenarien eine gemeinsame Datenzugriffsschicht auf Server und Clients zu haben. Ansonsten nimmt man auf dem Desktop und Server lieber doch besser das etablierte Entity Framework 6.1.
Für eine neu zu entwickelnde Webanwendung ist ASP.NET Core 1.0 auf .NET Core 1.0 nur eine Alternative zu ASP.NET MVC 5.x, wenn man mit der aktuell geringeren Feature-Ausstattung von ASP.NET Core 1.0 klarkommt. Ein Zwischenschritt, den Microsoft bewusst anbietet, könnte sein, eine ASP.NET-Core-Webanwendungen auf dem .NET "Full" Framework 4.6.x zu betreiben. Dann hat man zwar einen Fuß in der Tür zur Core-Welt, dennoch stehen alle .NET-Basisklassen und auch -Erweiterungen zur Verfügung (mit Ausnahme der ASP.NET-MVC-Erweiterungsbibliotheken, die es noch nicht für ASP.NET Core gibt). Webanwendungen komplett auf ASP.NET Core und .NET Core umzustellen, macht allenfalls Sinn, wenn man unbedingt auch auf Linux hostbar sein muss. Diesen Antrieb werden aber nur sehr wenige haben.
In Summe haben wir mit .NET Core 1.0 nicht viel mehr als eine weitere Vorabversion für das .NET der Zukunft. .NET Core muss in den kommenden Releases noch reifen, für die es aber noch keinen öffentlichen Zeitplan gibt. .NET-Entwickler warten also weiter gespannt auf den Tag, an dem sie bestehende Anwendungen mit Begeisterung und vertretbarem Aufwand auf .NET Core umstellen können, um mit dem Programmcode alle Betriebssysteme anzusprechen. (ane)
