.NET wird Open Source, na und?

22. Oktober 2015Dr. Gregor Segschneider und Dario Lueke

Microsoft ändert seine Strategie und gibt mehr und mehr Code rund um die .NET-Plattform frei. Warum tut Microsoft das? Bringt es Vorteile, wenn jeder auf den Source-Code zugreifen darf? Und hat es Konsequenzen für die Softwareentwicklung mit .NET? Diese und andere Fragen kamen uns in den Sinn, als wir von diesem Schritt hörten. Aber ein etwas genauerer Blick auf die Pläne und Zwischenergebnisse überraschte uns doch sehr.

Bereits im April 2014 gründete Microsoft die .NET-Foundation, eine Non-Profit-Or­ga­ni­sa­ti­on mit der Aufgabe, Open-Source-Projekte zu fördern. Zum Start stellte Microsoft 24 Projekte unter die Verwaltung der Foundation. Die Ernsthaftigkeit der Open-Source-Initiative wird erkennbar, wenn man sich anschaut, welche Projekte übergeben wurden: die neue .NET Compiler Platform („Roslyn“) sowie eine Vielzahl von Projekten der ASP.NET-Familie. Zum aktuellen Zeitpunkt finden sich dort knapp 40 Projekte, unter denen auch prominente Namen wie Entity Framework, Microsoft Azure SDK for .NET, NuGet, WCF, MSBuild und das .NET Micro Framework vertreten sind.

Was hat Microsoft davon?

Auch wenn die Projektnamen schon eindrucksvoll klingen – was hat Microsoft davon, den Code der Öffentlichkeit zur Verfügung zu stellen? Unserer Meinung nach, kann man die Frage mit Innovation und Akzeptanz beantworten. Da jeder Einsicht in den Code nehmen kann, steigt automatisch das Vertrauen in die Software. Jeder kann sich den Code durchlesen und Verbesserungen sowie neue Features vorschlagen. Der Code wird „lebendiger“. Fehler oder Sicherheitslücken fallen im Mehr-Augen-Prinzip schneller auf. Unerwünschte Funktionalitäten, wie z.B. das Ausspionieren von Benutzern, wären direkt für jeden lesbar. Das führt dazu, dass es sich schnell in der Öffentlichkeit verbreitet und einen Imageverlust für den Hersteller bedeuten kann – das gilt es selbstverständlich zu vermeiden. Daher kann man bei Open-Source-Software davon ausgehen, dass sie nur das tut, was man als Benutzer möchte. Sollte dies nicht der Fall sein, hätte man sogar die Möglichkeit, den Source-Code seinen Bedürfnissen anzupassen und die modifizierte Software für sich selbst zu nutzen. Ein weiterer Aspekt von Open Source sind Kollaborationen bzw. Kooperationen. Das lässt sich sehr gut am Beispiel Mono verdeutlichen: In der Vergangenheit musste das .NET Framework im Mono-Projekt mühsam nachgebaut werden. Dies führte u.a. zu einem Streitfall mit Microsoft, der auf einer Verletzung von Software-Patenten basierte. Das gehört nun der Vergangenheit an: Die .NET-Foundation bietet Rechtssicherheit, da sie für die Projekte verantwortlich ist und den Source-Code unter diverse öffentliche Lizenzen gestellt hat. Somit ist jeder berechtigt, den originalen Code für seine eigenen Projekte – seien es kommerzielle oder Open-Source-Projekte – zu nutzen. Am Beispiel von Mono zeigt sich der Vorteil: Das Mono-Projekt kann direkt den originalen Code nutzen und spart sich dadurch den Aufwand und das Risiko, die Funktionalität nachzubauen. Dadurch ist Mono zukünftig in der Lage, deutlich schneller und besser mit dem .NET Framework mitzuwachsen.

Das ist ja schön für Mono. Aber wie hilft das Microsoft? Microsoft setzt so seine Cross-Platform-Strategie um. Diese Strategie ist für Entwickler schon durch die Unterstützung von Xamarin oder Cordova in der .NET-Entwicklungsumgebung Visual Studio spürbar. Im ersten Quartal des nächsten Jahres werden sich dann auch noch ASP.NET 5 und .NET Core 5, die beide ebenfalls Open-Source-Projekte sind, dazugesellen und damit einen Umbruch für die .NET-Plattform einleiten. Um dies zu verdeutlichen, müssen wir jedoch ein wenig weiter ausholen.

Aktuell ist es so, dass Microsoft unterschiedliche Stacks für die verschiedenen Plattformen bereitstellt und pflegt. Je nach Projekttyp, den man bei der Anlage im Visual Studio wählt, baut die Lösung auf einem dieser Stacks auf und bietet damit die volle Unterstützung und den vollen Feature-Umfang auf diesem Stack. Die Kehrseite der Medaille ist, dass die Lösung nicht auf andere Stacks übertragen werden kann. Auf den ersten Blick stellt dies erstmal kein Problem dar. Möchte man aber z.B. eine Assembly, die lediglich POCOs enthält, als DTOs verwenden und in einem ASP.NET 4 und einem Windows-Phone-Projekt nutzen, bemerkt man diese Einschränkung. Aus diesem Grund kamen 2011 die sogenannten Portable Class Libraries (PCL) auf. In diesen PCLs lassen sich die verschiedenen Stacks auswählen und miteinander kombinieren. Aus der gewählten Kombination werden Contracts vorgegeben, die quasi eine Schnittmenge an Funktionalitäten der verschiedenen Stacks widerspiegeln. Diese PCL kann dadurch in alle Projekte eingebunden werden, auf dessen Stack sie abzielt. Die Auflösung der Contracts geschieht dann zur Laufzeit, indem die Contracts im jeweiligen Stack aufgelöst werden. Diese geschieht in der Regel im Global Assembly Cache (GAC).

blog
Abbildung 1: Die unterschiedlichen Stacks der .NET Plattform (siehe http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx)

Der .NET Core basiert jedoch auf einem völlig anderen Konzept. Hier wird eine Verschmelzung der Stacks herbeigeführt, indem die Framework-Anteile für alle gleich sind. Lediglich die Runtime und die App Models sind dann noch spezifisch. Und das Besondere: Alle Komponenten des .NET Cores werden als NuGet Packages geliefert und müssen somit nicht mehr über den GAC aufgelöst werden. Dazu gehört auch die jeweilige Runtime. So bringt eine auf dem .NET Core entwickelte Lösung bereits alles mit, was sie zur Ausführung benötigt und ist nicht mehr auf installierte Komponenten angewiesen. Dadurch, dass ein .NET-Core-Projekt keine Referenzen auf Stack-spezifische Assemblies hat, können diese Projekte auch überall referenziert und genutzt werden. Ziel dieses Konzepts ist es, .NET-Core-Projekte nicht nur Stack-übergreifend zu nutzen, sondern es bietet auch das Potential, .NET-Core-basierte Lösungen plattformübergreifend zu betreiben. Dies ist möglich, indem eine CoreCLR auch für Linux und MacOS angeboten werden soll. Zusätzlich bieten die NuGet Packages kürzere Innovationszyklen. Während das .NET Framework meistens mit einem Update oder mit einer neuen Version von Windows ein Update erhält, ist der .NET Core diesen Zeiten nicht unterworfen. Entwickler können sich ihren .NET Core aus beliebigen Versionen der Packages selbst zusammenstellen. Es birgt jedoch das Risiko von Konflikten zwischen den Packages. Um dem vorzubeugen, sollen die NuGet Packages .NET Core zusätzlich vierteljährlich in Distributionen angeboten werden. Diese Distributionen enthalten alle zu dem Zeitpunkt aktuellen Packages und sind in ihrer Interoperabilität getestet. Sie sollen auch heruntergeladen und installiert werden können, sodass die NuGet Packages bereits im Package Cache auf den Entwicklungs- und Build-Umgebungen vorhanden sind und nicht während des Kompilierens aus dem Internet geladen werden müssen.

blog_

Abbildung 2: Stack-übergreifende BCL des .NET Core (siehe http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx)

Aktuell befindet sich der .NET Core noch in der Beta-Phase. Interessierte können es aber schon testen. Visual Studio 2015 bringt alles Notwendige mit.

Teilen Sie unsere Meinung? Erkennen Sie das Potential? Diskutieren Sie mit uns über diesen spannenden Umbruch in der .NET Entwicklung. Wir freuen uns auf Ihre Meinung.

Dr. Gregor Segschneider und Dario Lueke Dr. Gregor Segschneider und Dario Lueke sind beide für adesso tätig. Dr. Gregor Segschneider ist Senior Software Architekt. Seit den Anfängen von .NET entwickelt er Konzepte und Lösungen auf Grundlage dieser Technologie. Dario Lüke arbeitet als Software Architekt und entwickelt bereits seit über 10 Jahren Lösungen auf Basis der .NET- Technologien. Seine Erfahrungen reichen von Web- und Desktop-Anwendungen bis hin zu mobilen Lösungen.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentar hinzufügen:

Ihr Kommentar: