Microsoft will ASP.NET Core nicht mehr auf dem klassischen .NET anbieten Update

Auf das neue ASP.NET Core frühzeitig zu setzen, birgt wohl seine Risiken. Denn Microsoft will mit der nächsten größeren Version des Webframeworks nicht mehr das klassische .NET Framework 4.x unterstützen.

 –  29 Kommentare
Microsoft will ASP.NET Core nicht mehr auf dem klassischen .NET anbieten

Ein Argument für ASP.NET Core ist die Möglichkeit, das neue Webframework nicht nur auf dem noch lückenhaften .NET Core 1.x, sondern auch auf dem ausgereiften .NET Framework 4.x zu betreiben. Nun hat Microsoft im Quellcode für das zum dritten Quartal 2017 geplante ASP.NET Core 2.0 die Unterstützung für .NET Framework 4.x herausgenommen und damit viele Entwickler vor dem Kopf gestoßen, wie die lange, hitzige Diskussion auf GitHub zeigt.

ASP.NET Core ist eine von Grund auf neu gestaltete Implementierung von Microsofts etabliertem Webframework ASP.NET MVC. Ersteres ist im letzten Jahr nach mehrjähriger Entwicklungszeit als Version 1.0 erschienen und aktuell auf dem Versionsstand 1.1.1. Entwickler haben bisher die Auswahl, ASP.NET Core auf .NET Core 1.x oder .NET Framework 4.x zu betreiben. Das .NET Framework 4.x wird dabei umgangssprachlich auch als .NET "Full" Framework oder .NET "Desktop" Framework bezeichnet wird, auch wenn man damit seit Anfang auch Serveranwendungen realisieren konnte.

In den Beta-Versionen von ASP.NET Core 1.x waren die Projektvorlagen sogar so angelegt, dass immer Kompilate für .NET Core und .NET "Full" Framework entstanden. Die endgültigen Projektvorlagen sehen vor, dass man sich zu Projektbeginn entscheidet, später aber noch umsteigen kann. Viele Entwickler haben dabei auf die Full-Framework-Option gesetzt, da in .NET Core nicht nur viele elementare Funktionen fehlen (z. B. E-Mail-Versand), sondern auch viele Zusatzbibliotheken von Microsoft und Drittanbietern bisher nicht auf .NET Core laufen. Mit dieser Entscheidung ist eine spätere Migration auf .NET Core nicht ausgeschlossen.

Microsoft hatte in .NET Core 1.x bewusst zahlreiche Klassen und Klassenmitglieder weggelassen, um die Klassenbibliotheken zu verschlanken und alte Techniken wie DataSet, DataTables und Application Domains zu beerdigen. Dann aber folgte die von den Nutzern positiv aufgenommene Entscheidung, die Basisklassen des kommenden .NET Core 2.0 an die des .NET Framework 4.6.x anzugleichen und diese gemeinsame Basis ".NET Standard 2.0" zu nennen. Die Basisklassen umfassen aber dabei keineswegs die gesamte .NET Framework Class Library, die in .NET 4.6.x/4.7 rund 13.500 Klassen stark ist, sondern nur einen Bruchteil davon.

Für .NET Standard 2.0 geplante Klassen (Bild: Microsoft)

Microsoft-Mitarbeiter gehen in ihren Stellungnahmen (z. B. Produktmanager Scott Hanselman) auf GitHub davon aus, dass diese Basisklassen nun in .NET Core 2.0 ausreichen, um den Betrieb von ASP.NET Core 2.0 auf dem klassischen .NET Framework 4.x nicht mehr anbieten zu müssen. In .NET Core 2.0 kann man für .NET Framework 4.x geschriebene Assemblies referenzieren, sofern diese nur den von .NET Standard 2.0 gesetzten Klassenrahmen benötigen.

Auch wenn Microsoft in der GitHub-Diskussion bereits zugesagt hat, neben den .NET-Standard-2.0-Klassen nicht dort enthaltene Klassenbibliotheken wie System.DirectoryService (für LDAP-Programmierung) und System.Drawing (für das Erstellen und Bearbeiten von Grafiken) dieses Jahr schon für .NET Core 2.0 zu liefern, kann das die Entwickler nicht beruhigen, da zahlreiche beliebte Drittanbieterkomponenten eben nicht mit dem Klassenumfang von .NET Standard 2.0 auskommen und daher nicht auf .NET Core 2.0 laufen werden können. Das verhindert folglich den Einstieg in ASP.NET Core 2.0 beziehungsweise den Umstieg von ASP.NET Core 1.x auf .NET Framework 4.x zu ASP.NET Core 2.0 auf .NET Core 2.0.

Laut Analyse eines Benutzers fehlen zum Beispiel für den Betrieb des OR-Mappers NHibernate und der Service-Bus-Lösung NServiceBus in .NET Standard 2.0 jeweils ein Drittel der benötigten Klassen. Aber auch Microsoft-Programme, die auf COM-Interoperabilität basieren (z. B. die komplette Microsoft-Office-Automation), haben keine Chance auf den .NET Standard 2.0, da COM-Interoperabilität dort nicht implementiert ist.

Microsoft-Entwickler David Fowler nennt als Grund für die fehlende Unterstützung von .NET Framework 4.x in ASP.NET Core 2.0 die Tatsache, dass Microsoft in ASP.NET Core 2.0 auf APIs setze, die es in .NET Core 2.0, aber nicht im .NET Standard 2.0 gäbe. Einige dieser APIs benennt er. Naheliegend wäre, dass Microsoft diese APIs auch in die nächste Version von .NET Framework 4.x einarbeitet. Laut Fowler sind damit aber Risiken für die Kompatibilität verbunden, die Microsoft anscheinend nicht eingehen will.

Erschwerend kommt hinzu, dass Microsoft für .NET Core die Support-Zeiträume radikal verkürzt hat. Während es für jede Version des klassischen .NET Framework zehn Jahre Unterstützung gab, ist für .NET-Core-Hauptversionen nur noch ein Jahr Unterstützung nach dem Erscheinen der nächsten Hauptversion vorgesehen. Wenn ASP.NET Core 2.0 dieses Jahr erscheinen wird, ist für Nutzer von ASP.NET Core 1.x also schon 2018 das Supportende erreicht. Viele Nutzer haben starke Zweifel, dass bis dahin alle benötigten Bibliotheken für .NET Core 2.0 verfügbar sein werden. Die Entwickler können also nicht das Problem mit ASP.NET Core 1.1.1 auf dem .NET Framework 4.x aussitzen, bis .NET Core beziehungsweise die Drittanbieterkomponenten entsprechend gereift sind.

Heute beginnt Microsofts diesjährige Build-Konferenz. Man darf gespannt sein, wie die offiziellen Verlautbarungen zu diesem kontroversen Thema sein werden. Die Keynote wird am Mittwoch ab 17 Uhr deutscher Zeit live im Internet zu sehen sein.

[Update 11.5. 08:15]

Offensichtlich hat Microsoft auf die Kritik der Entwickler reagiert, wie an einem Blogbeitrag auf MSDN erkennbar ist. Das Team will sicherstellen, dass es keine Probleme beim Upgrade von ASP .NET Core 1.0 auf Version 2 geben wird. (Holger Schwichtenberg) / (ane)