Zuerst hieß es .NET Framework 5. Doch dann überraschte uns die Marketingabteilung von Microsoft und gab der neuen quelloffenen und plattformunabhängigen Version den Namen .NET Core. Das macht insofern Sinn, da das neue Framework ein anderes ist als das, was wir seit Anfang der 2000er vom Windows-Desktop her kennen. Unsere klassischen .NET-Anwendungen (WinForms, WPF, ASP.NET etc.) laufen hier nicht. Der Softwarehersteller aus Redmond verpasst dem Framework damit einen Neustart.
Dann ist da noch die Firma Xamarin, die von Microsoft übernommen wurde. Damit befindet sich nun auch Mono in der Obhut von Microsoft. Mono ist eine quelloffene und plattformunabhängige Implementierung des .NET Frameworks, basierend auf den ECMA-Standards für C# und der Common Language Runtime [1]. Gleiches gilt für das Produkt Xamarin. Mit Xamarin lassen sich native Apps für verschiedene Plattformen (Android, iOS, Windows Universal Platform) in C# entwickeln. Unter der Haube setzt Xamarin dabei auf Mono.
Apropos „nativ“: Im Rahmen der Windows-Store-Apps veröffentlichte Microsoft .NET Native [2]. Im Wesentlichen stellt .NET Native einen Ahead-of-Time-(AoT-)Compiler zur Verfügung, der eine .NET-Anwendung (Windows-Store-App) in nativen Code übersetzt. Der Windows Store liefert dann den für die Zielplattform spezifischen nativen Code an den Benutzer aus.
Und als wäre das noch nicht genug, setzte Microsoft noch eins drauf und kündigte 2016 .NET Standard [3] an (damals noch .NET Platform Standard genannt). Nach sieben Versionen steht man hier nun bei der Version 2.0, die kürzlich veröffentlicht wurde.
Es lässt sich nicht abstreiten, dass sich rund um .NET viel tut. Dass man da als Entwickler schnell den Überblick verlieren kann oder sich in einem Zustand der Verwirrung und Orientierungslosigkeit wiederfindet, ist mehr als verständlich.
Abb. 1 In der Geschichte von .NET entstanden viele Ausprägungen (Verticals), meist aus einem Fork des großen .NET Frameworks
Der .NET Framework & C# Track auf der BASTA! Konferenz
Moderne Anforderungen
Schauen wir einmal auf Abb. 1. Wenn wir bisher von Portabilität geredet haben, dann betraf das nur die Microsoft-Windows-Plattformen. Plattformunabhängigkeit ist das noch lange nicht. Im Zeitalter der Cloud stellt sich die Frage, wie es mit anderen Plattformen aussieht: Linux, Mac und Containertechnologien lauten hier die Schlagwörter. Lange hat Amazon mit den Amazon Web Services (AWS) eine Cloud-Plattform etabliert, auf der das .NET Framework keine Rolle spielt. Und lässt man einmal Mono außer Acht, laufen herkömmliche .NET-Anwendungen auch nicht auf Linux-Distributionen oder auf dem Mac. Möchte Microsoft seine Kunden also auf derartige Plattformen bekommen, so muss eine andere, neue Lösung her. Und diese Lösung muss leichtgewichtig sein. Mal ebenso mehrere hundert oder tausend Container innerhalb von ein paar Sekunden hochziehen? Mit einem Windows-OS, vielleicht noch einer MSSQL-Datenbank und dem .NET Framework fühlt es sich an, als würde man versuchen, einen voll geladenen Jumbojet mit eigener Puste in den Himmel zu heben.
Dass .NET Core die Zukunft des .NET Frameworks sein muss, liegt aus technischer Sicht auf der Hand.
In diesem Kontext spielt auch die Modularität eine entscheidende Rolle. Wurde doch das .NET Framework als ein monolithisches Stück Software konzipiert, das auf dem Zielsystem als Ganzes installiert werden muss. Mittlerweile hat das Framework mehrere hundert Megabyte im Gepäck. Damit ergibt sich ebenfalls eine systemweite Abhängigkeit von Anwendungen zur installierten Version des .NET Frameworks. Erfordert eine Anwendung eines anderen Herstellers eine neuere Version des Frameworks, so kann sich dies auf bereits installierte Applikationen auswirken. Dafür möchte am Ende kein Systemadministrator verantwortlich sein. Wünschenswert wäre es, wenn diese systemweite Abhängigkeit von einer Anwendung zum Framework keine Rolle spielt. Das würde funktionieren, wenn Applikationen alles mitbringen könnten, was sie benötigen (inklusive der Laufzeitumgebung), und wenn diese Abhängigkeiten pro Anwendung installiert werden könnten. Dann wären die Versionen der Laufzeitumgebung und abhängigen Bibliotheken egal. Zudem würde das den Speicherbedarf reduzieren. Denn Anwendungen bringen nur das mit, was sie wirklich benötigen. Dazu gehört mit Sicherheit nicht das mehrere hundert Megabyte große .NET Framework. Wir sprechen hier von einem applikationslokalen Framework. Ein Monolith als maschinenweites Framework erfüllt diese Anforderung natürlich nicht.
Mit einem Windows-OS, vielleicht noch einer MSSQL-Datenbank und dem .NET Framework fühlt es sich an, als würde man versuchen, einen voll geladenen Jumbojet mit eigener Puste in den Himmel zu heben.
.NET Core im richtigen Licht
Der kritische Leser mag nun behaupten, dass .NET Core auch nichts anderes sei, als ein weiteres Vertical – ein weiterer .NET Stack. Zu Recht, denn genau das ist .NET Core. Dennoch: Laut Microsoft ist .NET Core ein Neustart des .NET Frameworks. Von Grund auf unter anderen Voraussetzungen als das ursprüngliche, monolithische .NET Framework konzipiert – basierend auf Anforderungen moderner Softwareanwendungen. Für Microsoft ist .NET Core der .NET-Stack der Zukunft und soll als Fundament für alle kommenden Plattformen und Hardwarearchitekturen dienen. Funktioniert das auf irgendeine Art und Weise zukünftig in der Praxis nicht, dann ist es wirklich nur ein weiterer .NET-Stack, den wir ggf. mit unseren Anwendungen bedienen müssen. Das ist aber eher unwahrscheinlich angesichts dessen, was gerade rund um .NET Core geschieht. Nicht ohne Grund presst Microsoft APIs mit Nachdruck in die neuen Versionen von .NET Core und forciert damit die API-Konvergenz – zum großen .NET Framework, aber auch zu anderen Verticals. Doch dazu später mehr.
Dass .NET Core die Zukunft des .NET Frameworks sein muss, liegt aus technischer Sicht auf der Hand: es löst die besagten Probleme der Vergangenheit und erfüllt damit die Anforderungen, die moderne Anwendungen für Web, Cloud, IoT, mobile Geräte etc., an ein solches Framework stellen.
