Analyse: .NET wird zunehmend modularer

In einer kommenden .NET-Variante besteht auch das Framework selbst aus mehreren Softwarekomponenten.

In Pocket speichern vorlesen Druckansicht 2 Kommentare lesen
Lesezeit: 4 Min.
Von
  • Dr. Holger Schwichtenberg
Inhaltsverzeichnis

In einer kommenden .NET-Variante besteht auch das Framework selbst aus mehreren Softwarekomponenten.

Diese Woche sprach ich im Rahmen einer Strategieberatung mit einem Kunden auch über die zunehmende Modularisierung des .NET Framework. Dabei entstanden am Flipchart einige Zeichnungen, die ich gerne mit der Öffentlichkeit teilen möchte. Die Grafiken können unter Beibehaltung meines Urhebervermerks gerne in Präsentationen und Veröffentlichung weiterverwendet werden. Die Größe der Kästen sind bewusst nicht proportional zur Anzahl der Klassen, da sonst die Darstellung sehr viel Platz verbrauchen würde.

In der ersten Entwicklungsphase des .NET Framework bis 2010 wuchsen die Funktionalität und damit auch die Anzahl der Klassen im Installationspaket des .NET Framework (".NET Framework Redistributable") stark an (siehe Abbildung 1). Es gab von Anfang an Zusatzkomponenten von Microsoft (hellblau dargestellt) und anderen kommerziellen und nichtkommerziellen Anbietern (orange dargestellt). Auch die Anzahl dieser zusätzlichen Setups ist stark gewachsen.

.NET-Modularisierung: Erste Entwicklungsphase des .NET Framework bis 2010 (Abb. 1)

(Bild: Holger Schwichtenberg)

2010 wurde der Softwarekomponentenverteilungsmechanismus NuGet eingeführt. Inzwischen liefert Microsoft alle Zusatzkomponenten dort aus. Außerdem gibt es seit 2013 innerhalb von nuget.org eine Trennung in offizielle Zusatzkomponenten und andere Komponenten. Im Feed "Microsoft and.NET" stellt Microsoft jene Teilmenge der Zusatzkomponenten bereit, für die es offiziellen und kommerziellen Produktsupport gibt. Die Funktionalität des .NET Framework Redistributables ist weniger gewachsen als in der ersten Phase. Anders als das mächtige .NET-Update 3.5.1 im Jahr 2008 sind .NET Framework 4.5.1 (2013) und 4.5.2 (2014) nur marginale Ergänzungen. Die meisten Innovationen findet man in den NuGet-Paketen, die zum Teil in sehr kurzen Zyklen aktualisiert werden.

Modularisierung seit der Einführung von nuget.org 2010 und des "Microsoft und .NET"-Feeds 2013 ( (Abb. 2)

(Bild: Holger Schwichtenberg)

Im Mai 2014 hat Microsoft dann auf der TechEd-Konferenz in Housten das "ProjectK" verkündet. Hinter diesem Codenamen verbirgt sich eine neue Version des .NET Framework, die nicht mehr aus einem großen monolithischen Setup besteht, sondern aus mehreren einzelnen Komponenten, die man bei nuget.org bei Bedarf herunterladen kann. Microsoft nennt dieses Konzept "NuGet Everything".

Zunächst wird dieses modulare .NET für ASP.NET-Anwendungen auf dem Server eingesetzt (vgl. TechEd-Nachricht "ASP.NET vNext: Aus MVC, WebAPI und Web Pages wird MVC 6"). Eine Verwendung in anderen Anwendungsgebieten ist jedoch naheliegend, zumal Microsoft auch im administrativen Bereich ebenfalls eine Paketierungsstrategie verfolgt (vgl. "OneGet" und "PowerShellGet" im kommenden PowerShell 5.0.

Noch sind "Project K", "ASP.NET vNext" und PowerShell 5.0 im frühen Alpha-Stadium. Erscheinen werden diese Produkte erst 2015. Produktiv einsetzen kann man sie heute noch nicht. Aber ausprobieren geht schon mit dem der dritten CTP-Version von Visual Studio 14 und der Windows Management Framework 5.0 Preview.

Microsoft entwickelt nun an einer Version des .NET Frameworks, das aus Nuget-Komponenten besteht (Abb. 3)

(Bild: Holger Schwichtenberg)

Angesichts der heutigen Endgerätesituation und der oftmals geforderten schnellen Innovation sind monolithische Softwarekolosse nicht mehr zeitgemäß. Die Modularisierung von .NET ist hilfreich, um die Verbreitung von .NET zu fördern. Andererseits wird die .NET-Welt durch die vielen Pakete immer unübersichtlicher und fehleranfälliger, weil man sich als Entwickler erst einmal die notwendigen oder zueinander passenden Pakete zusammensuchen muss, während man früher mit einem Setup alles auf dem System hatte.

Bleibt nur zu hoffen, dass Microsoft die verschiedenen Paketierungsansätze zu einem gemeinsamen Konzept zusammenführt – und zwar schon in der ersten Version und nicht erst nach den Kundenbeschwerden in der zweiten oder dritten Version. ()