© mundoview/Shutterstock.com © S&S Media
Windows Developer
Teil 3: .NET Core im richtigen Licht

Einer für alle - .NET Standard

Im zweiten Teil dieser Artikelserie wurde gezeigt, wie Microsoft mit dem Neustart des .NET Frameworks, namentlich .NET Core, die Probleme der Vergangenheit aus dem Weg räumen will. .NET Core bringt dabei Modularität, Leichtgewichtigkeit, Plattformunabhängigkeit und Interoperabilität. Was ist nun aber .NET Standard? Wozu brauchen wir diesen Standard? Und wie passt er in das Gesamtbild? Diese Fragen sollen im letzten Teil dieser Serie beantwortet werden.

Robin Sedlaczek


ArtikelserieTeil 1: Entwirrspiel: Plattformunabhängigkeit und KompatibilitätTeil 2: .NET Core als LösungsansatzTeil 3: .NET Core im richtigen Licht

.NET Core löst die Probleme der Plattformunabhängigkeit und Portabilität und eliminiert damit viele der in den vorigen Artikeln genannten .NET Verticals – viele, aber eben nicht alle. Und genau dieser Umstand stellt eine weitere Herausforderung dar: Was ist mit gänzlich anderen .NET-Plattformen wie z. B. Mono und folglich Xamarin, das auf Mono basiert? Und wie steht es um .NET-Plattformen von anderen Anbietern, die möglicherweise in Zukunft in Erscheinung treten? Wieder die Frage der Kompatibilität und Portabilität: Können eigene Softwarekomponenten ohne Weiteres auf diesen Plattformen eingesetzt werden? Die Antwort lautet erst einmal nein. Abbildung 1 zeigt das Problem.

Im linken Teil von Abbildung 1 sind die drei größten momentan existierenden .NET-Plattformen dargestellt. Zum einen haben wir das klassische .NET Framework für den Desktop. Daneben existiert nun .NET Core. Die dritte Plattform ist Xamarin, das seinerseits auf Mono basiert. Das Problem daran ist, dass jede dieser drei .NET-Plattformen mit ihrer eigenen Klassenbibliothek daherkommt. Für das klassische .NET Framework ist das die Base Class Library (BCL), für .NET Core die Core Library und für Xamarin die Mono Class Library. Diese Klassenbibliotheken sind nicht vereinheitlicht. Somit stehen wir wieder genau vor dem gleichen Problem wie mit den .NET Verticals: Komponenten sind nicht so einfach zwischen diesen Plattformen austauschbar bzw. wiederverwendbar. Code muss für jede adressierte Plattform spezifisch angepasst werden. Das wiederum führt zu erheblichem Mehraufwand und dupliziertem Code. Ein Problem, das gelöst werden muss.

.NET Standard

An dieser Stelle kommt .NET Standard ins Spiel. .NET Standard ist der Versuch, die Klassenbibliotheken zu vereinheitlichen (Abb. 1 rechts). Im Prinzip umfasst der Standard eine Reihe von API-Spezifikationen. die von allen .NET-Plattformen implementiert werden müssen. .NET Standard unterliegt zudem einer strikten Versionierung, um eine Zuordnung der spezifizierten APIs zu einer Version gewährleisten zu können. Erfüllt eine .NET-Plattform eine bestimmte Version des Standards, so wird zugesichert, dass alle APIs von der Plattform unterstützt werden, die in der Version spezifiziert sind. Softwarekomponenten werden dann gegen eine Version des Standards kompiliert. Ist das der Fall, können diese Komponenten auf allen ...

Windows Developer
Teil 3: .NET Core im richtigen Licht

Einer für alle - .NET Standard

Im zweiten Teil dieser Artikelserie wurde gezeigt, wie Microsoft mit dem Neustart des .NET Frameworks, namentlich .NET Core, die Probleme der Vergangenheit aus dem Weg räumen will. .NET Core bringt dabei Modularität, Leichtgewichtigkeit, Plattformunabhängigkeit und Interoperabilität. Was ist nun aber .NET Standard? Wozu brauchen wir diesen Standard? Und wie passt er in das Gesamtbild? Diese Fragen sollen im letzten Teil dieser Serie beantwortet werden.

Robin Sedlaczek


ArtikelserieTeil 1: Entwirrspiel: Plattformunabhängigkeit und KompatibilitätTeil 2: .NET Core als LösungsansatzTeil 3: .NET Core im richtigen Licht

.NET Core löst die Probleme der Plattformunabhängigkeit und Portabilität und eliminiert damit viele der in den vorigen Artikeln genannten .NET Verticals – viele, aber eben nicht alle. Und genau dieser Umstand stellt eine weitere Herausforderung dar: Was ist mit gänzlich anderen .NET-Plattformen wie z. B. Mono und folglich Xamarin, das auf Mono basiert? Und wie steht es um .NET-Plattformen von anderen Anbietern, die möglicherweise in Zukunft in Erscheinung treten? Wieder die Frage der Kompatibilität und Portabilität: Können eigene Softwarekomponenten ohne Weiteres auf diesen Plattformen eingesetzt werden? Die Antwort lautet erst einmal nein. Abbildung 1 zeigt das Problem.

Im linken Teil von Abbildung 1 sind die drei größten momentan existierenden .NET-Plattformen dargestellt. Zum einen haben wir das klassische .NET Framework für den Desktop. Daneben existiert nun .NET Core. Die dritte Plattform ist Xamarin, das seinerseits auf Mono basiert. Das Problem daran ist, dass jede dieser drei .NET-Plattformen mit ihrer eigenen Klassenbibliothek daherkommt. Für das klassische .NET Framework ist das die Base Class Library (BCL), für .NET Core die Core Library und für Xamarin die Mono Class Library. Diese Klassenbibliotheken sind nicht vereinheitlicht. Somit stehen wir wieder genau vor dem gleichen Problem wie mit den .NET Verticals: Komponenten sind nicht so einfach zwischen diesen Plattformen austauschbar bzw. wiederverwendbar. Code muss für jede adressierte Plattform spezifisch angepasst werden. Das wiederum führt zu erheblichem Mehraufwand und dupliziertem Code. Ein Problem, das gelöst werden muss.

.NET Standard

An dieser Stelle kommt .NET Standard ins Spiel. .NET Standard ist der Versuch, die Klassenbibliotheken zu vereinheitlichen (Abb. 1 rechts). Im Prinzip umfasst der Standard eine Reihe von API-Spezifikationen. die von allen .NET-Plattformen implementiert werden müssen. .NET Standard unterliegt zudem einer strikten Versionierung, um eine Zuordnung der spezifizierten APIs zu einer Version gewährleisten zu können. Erfüllt eine .NET-Plattform eine bestimmte Version des Standards, so wird zugesichert, dass alle APIs von der Plattform unterstützt werden, die in der Version spezifiziert sind. Softwarekomponenten werden dann gegen eine Version des Standards kompiliert. Ist das der Fall, können diese Komponenten auf allen ...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang