Von Microsoft sehen wir oft Auflistungen von Features und große Show-Präsentationen. Oft bleibt aber unklar welchen konkreten Business-Wert diese Features bringen. Auch Entwickler haben oft Probleme einen Umstieg zu rechtfertigen. Deshalb gehen wir mit diesem Blog-Post auf die neuen Features, aus Sicht des Nutzens, genauer ein. Aufgrund der Größe und des Feature-Reichtums des neuen .NET 2015 beschränken wir uns ausschließlich zunächst auf .NET Core und behandeln ASP.NET 5 und .NET 4.6 in folgenden Posts.
Was sind also die neuen Features und welche Auswirkungen haben Sie auf das Business?
Open Source
Dabei denken viele im ersten Moment an abstürzende Software und Bugs. Microsoft, sowie viele andere auch, zeigen wie es auch anders geht. Dies würde aber den Rahmen dieses Posts sprengen. Der Business-Wert liegt in der neuen Dimension der Anpassbarkeit der Common-Language-Runtime. Sie benötigen speziellen Code zur Laufzeit für ihr eingebettetes System? Sie müssen jeden Aufruf von “File.Open” auf Ihrem System protokollieren? Sie betrifft ein CLR-Bug, können nicht auf das nächste Release warten und wollen ihn sofort beheben? Das alles ist jetzt möglich. Wenn sie jetzt aber an einen eigenen umfangreichen.NET Installer denken, dann werden Sie überrascht sein.
- Anpassbarkeit/Flexibilität
CLR als NuGet Paket
Ganz im Gegenteil wird jetzt die CLR von dem Framework abgetrennt, womit es nun möglich wird sowohl zwischen verschiedenen Laufzeiten zu wählen (.NET Core, Mono, .Net) als auch eine selbst erstellte Laufzeit zu nutzen. Dadurch ist man natürlich auch nicht mehr auf die installierte Version angewiesen, weshalb nun das Testen für verschiedene, bereits installierte, Laufzeiten entfällt (läuft meine Anwendung auch mit dem Update .Net 4.5.X?). Aus weniger Testaufwand folgen letztlich natürlich auch geringere Kosten. Man kann nun auch auf “festgefahrenen” Systemen die aktuellste Version seiner Software ausliefern ohne die Nutzer zu einer neuen .Net Version zu zwingen (und damit ggf. andere Anwendungen zu brechen).
- Wahl zwischen .NET Core, Mono, .NET und eigener Runtime (sowohl auf Basis von Mono als auch .NET Core)
- Testen verschiedener Versionen entfällt (.Net 4, .net4.5, .Net 4.5.1, …)
- Unabhängig von der Installierten Version. (Nur .Net 4.0 installiert –> egal)
Framework Libraries als NuGet Paket
Zusätzlich zur Entkopplung der Laufzeit wurde nun auch das Framework selbst in seine Einzelteile zerlegt und als NuGet Pakete zur Verfügung gestellt. Dies hat im Grunde dieselben Vorteile die auch für die Laufzeit gelten (Anpassbarkeit, Testen nur gegen eine Version usw.). Zusätzlich wird es aber nun für Microsoft möglich neue Versionen für Teile des Frameworks herauszugeben. Was natürlich dazu führt, dass man auf neue Versionen nicht mehr bis zum nächsten “großen” Release-Zyklus warten muss. Weiter ermöglicht dieses Aufbrechen des Frameworks, dass man nur .NET Framework Komponenten ausliefert, die auch benötigt werden. So kann man .NET nun auch auf Geräten nutzen für die eine komplette .NET Installation nicht möglich ist (ohne dabei auf APIs verzichten zu müssen!). Zusätzlich sind jetzt alle Abhängigkeiten vereinheitlicht: “System.Console” ist aus der Sicht des Projekts genau wie “Json.Net” eine NuGet-Abhängigkeit. Dies vereinheitlicht (=> weniger Kosten) natürlich den Umgang mit Abhängigkeiten sowohl im Entwicklungs- als auch den Test- und Release-Prozess.
- Einzelne Anpassungen möglich
- Nur benötigte Komponenten ausliefern
- .NET Framework: Einfach nur eine Bibliothek. Ein Prozess für alle Abhängigkeiten! .NET ist kein Spezialfall mehr.
Neues Packaging
Die Installation von .NET-Anwendung war in der Regel immer schon ein XCOPY-Deployment, allerdings mit der Einschränkung, dass das .NET Framework vorher schon, in der richtigen Version, installiert sein musste. Diese Einschränkung entfällt nun. Es gibt nun mit .NET Core diverse Deployment-Optionen. So ist es nun möglich mit Visual Studio 2015 ein Paket zu erstellen, welches alle Abhängigkeiten enthält und direkt gestartet werden kann. Andererseits kann man aber die Software auch dann direkt starten, wenn sie nur als Source-Code vorliegt! Es sind also völlig neue Deployment-Szenarien möglich. Schließlich kennt das neue Build-System nur noch die Abhängigkeiten und deren Versionen und zieht verschiedene Quellen in Betracht. So ist es nun möglich ein Paket durch dessen Quellcode zu ersetzen (dieser wird dann einfach beim Kompilierungsprozess mit erstellt), damit wird sowohl die Fehlerbehebung, die Fehleranalyse als auch der Wechsel (die Ausgliederung) von Projektteilen zu NuGet vereinfacht.
- Auflösen und packen der Abhängigkeiten zur Entwicklungszeit.
- Optional aber auch herunterladen der Abhängigkeiten zur Laufzeit (bevor das Programm startet)
- Direktes ausführen des Quellcodes (one-step auflösen und herunterladen der Abhängigkeiten)
- vereinheitlichte Abhängigkeiten –> Quelle kann NuGet, Dateisystem usw. sein.
- Produktivität, da man einfach zwischen Code und NuGet hin und herwechseln kann.
Cross Plattform
Der Name .NET Core ist wörtlich zu nehmen. Es handelt sich um den Kern. Das heißt, nun ist es möglich auf Geräte zu gehen für die es entweder nicht möglich war ein komplettes .NET Framework zu installieren, zum Beispiel eingebettete Geräte, oder bei denen man vorher auf spezifische Versionen angewiesen war (Cloud-Provider zum Beispiel). Weiter kann man nun bestehende Linux Infrastruktur mit seinen .NET Core Anwendungen nutzen und ggf. Lizenzkosten einsparen.
- Cloud-Ready
- (Lizenz-)Kosten minimieren
- Embedded Devices
- Bestehende (Linux) Infrastruktur nutzen
All diese Änderungen führen dazu, dass man sich nicht mehr auf veraltete Technologien beschränken muss, nur weil das Zielsystem nicht das neuste .NET installiert hat.
- Software läuft sowohl auf veralteten als auch auf neuen Rechnern (da alle Abhängigkeiten mitgeliefert werden)!
Nachteile bzw. wann sollte man nicht Umsteigen?
Nicht alle APIs sind (und werden) unterstützt. Will/Muss man eine solche API nutzen muss man auf dem normal .NET Framework bleiben. Des Weiteren ist nicht klar wir sich .NET Core entwickelt und ob, zum Beispiel bei fehlender Adaption, weiter von Microsoft voll unterstützt wird oder sich zum reinen Open-Source Projekt entwickelt. Diese (Rest-)Unsicherheit bleibt natürlich bei jeder neuen Technologie.
- Fehlende APIs: z.B.: AppDomains https://github.com/dotnet/coreclr/issues/642, https://github.com/dotnet/coreclr/issues/295
- Gute Designentscheidungen, aber Zukunft noch offen