April 2016

Band 31, Nummer 4

.NET wird mit .NET Core plattformübergreifend

Von Phillip Carter | April 2016

Bei Microsoft arbeiten wir an einer neuen Implementierung von .NET (genannt .NET Core), damit Sie plattformübergreifenden Code für Workloads schreiben können, der für die Cloud optimiert ist. Viele Benutzer sind von dieser Open Source-Entwicklung begeistert. Aber was bedeutet sie konkret? Dieser Artikel klärt darüber auf, wie sich .NET Core heute darstellt und welche Ziele verfolgt werden, welche Beziehung zu Microsoft .NET Framework besteht, und erläutert außerdem die Grundlagen der Befehlszeilentools, die Sie für Ihre ersten Schritte mit .NET Core verwenden können.

Was ist .NET Core?

Hilfreich für das Verständnis von .NET Core sind Kenntnisse von .NET. Viele Benutzer meinen „.NET Framework“, wenn sie „.NET“ sagen. Das stimmt aber nicht ganz. .NET ist ein ECMA-Standard mit verschiedenen Implementierungen – .NET Framework, Mono, Unity und jetzt auch .NET Core. Dies bedeutet, dass ein Großteil der Funktionalität für .NET Framework und .NET Core übereinstimmt. .NET Core ist jedoch neu und basiert auf einigen anderen Prinzipien.

Der erste Unterschied besteht darin, dass .NET Core plattformübergreifend ist. Die Ausführung kann unter Windows, OS X und verschiedenen Distributionen von Linux erfolgen. Außerdem werden verschiedene CPU-Architekturen unterstützt. Wir fügen zurzeit weiteren Support für Linux-Distributionen und CPU-Architekturen hinzu. Das Ziel dabei besteht darin, dass .NET Core so universell wie möglich eingesetzt werden kann.

Gleichzeitig sind das Design und die Architektur von .NET Core grundsätzlich modular. Die Laufzeit-, Bibliotheks- und Compilerkomponenten sind jeweils separate Entitäten, die über durchdachte Schnittstellen kommunizieren. Auf diese Weise können Sie Komponenten nach Ihren speziellen Bedürfnissen integrieren bzw. austauschen. Die Bibliotheken selbst sind ebenfalls modular und werden über NuGet verteilt. So können Sie nur die benötigten Elemente verwenden, damit Sie den Fußabdruck von .NET Core auf beliebigen Systemen optimieren können.

Außerdem ist für .NET Core geschriebener Code portabel. Er kann so optimiert werden, dass er auf verschiedenen unterstützten Plattformen ausgeführt werden kann. Abhängig davon, auf welche Ziele sich Ihre Projekte beziehen, ist es möglich, .NET Core-Code auf den .NET Framework-, Mono- und Xamarin-Plattformen, unter Windows 8 und Windows Phone sowie auf der UWP (Universelle Windows-Plattform) auszuführen. Weitere Informationen finden Sie im Standard für die .NET-Plattform (bit.ly/1Of6W1r).

Schließlich wird .NET Core als Pay-for-Play-Modell implementiert und zeichnet sich durch seine Leistungsfähigkeit aus. Ein Ziel bei der .NET Core-Entwicklung besteht darin, Entwicklern die Kosten von Abstraktion zu verdeutlichen, indem ein Pay-for-Play-Modell implementiert wird, das die Kosten offensichtlich macht, die mit der Bereitstellung einer Abstraktion auf höherer Ebene zum Lösen eines Problems einhergehen. Abstraktionen sind nicht kostenlos. Diese Wahrheit sollte Entwicklern immer bewusst sein. Außerdem ist .NET Core aufgrund einer Standardbibliothek leistungsorientiert, die Zuordnungen und den Gesamtfußabdruck Ihres Systems für den Speicher so gering wie möglich hält.

Szenarien für .NET Core

Zurzeit sind vier Szenarien denkbar, in denen Sie Code für .NET Core schreiben können: plattformübergreifende ASP.NET-Web-Apps, plattformübergreifende Konsolen-Apps, plattformübergreifende Bibliotheken und Frameworks sowie UWP-Apps

ASP.NET Core 1.0 ist geschwindigkeitsorientiert und stellt den plattformübergreifenden Webstapel für .NET Core dar. Wenn Sie sich jemals gewünscht haben, Ihre ASP.NET-Web-App in einem Container unter Linux bereitzustellen: Dies ist jetzt möglich. Weitere Informationen zum Funktionsumfang der ASP.NET Core-Angebote finden Sie in der Dokumentation unter bit.ly/1TqPcIo.

Der Umfang plattformübergreifender Konsolen-Apps ist tatsächlich viel größer als viele Entwickler erwarten würden. Eine ASP.NET Core-Web-App ist in ihrem Kern eine Konsolen-App, die Informationen aus Ports liest und in diese schreibt – sie führt nur noch zahlreiche weitere Aktionen aus. Eine Sammlung von Microservices, die das Back-End eines Gesamtsystems darstellen, könnte als Konsolen-Apps geschrieben werden.

Der Unterschied zwischen plattformübergreifenden Bibliotheken und Frameworks besteht in der Skalierung. Bibliotheken stellen eines der natürlichen Elemente für Erstellungsvorgänge in .NET Core dar. In einer viel größeren Skalierung sind jedoch auch Frameworks gute Kandidaten für verteilte Verarbeitung.

Schließlich können auch UWP-Apps, die die Produktfamilie der Windows 10-Geräte als Ziel verwenden, mit .NET Core ausgeführt werden. Sie können eine voll funktionsfähige UWP-App erstellen, die .NET Core-Bibliotheken umfasst, um das Erstellen reichhaltiger Windows 10-Apps zu unterstützen.

Sie können also schon heute vielfältigen Code für .NET Core schreiben. Wenn die Tools ausgereifter und vielfältiger werden, stehen in der Zukunft noch mehr Möglichkeiten zur Verfügung.

Wenn Sie über .NET Framework-Ressourcen verfügen, die in eines der vier genannten Szenarien passen, oder brennend an neuer Technologie interessiert sind, besuchen Sie bit.ly/1Q1Q18q, damit Sie mit dem Schreiben von .NET Core-Code beginnen können.

.NET Core im Vergleich zu .NET Framework

Die meisten von Ihnen kennen und schätzen „.NET“ als .NET Framework. Wie also sieht .NET Core im Vergleich zu .NET Framework aus? Zuerst sollten Sie sich bewusst machen, dass auch weiterhin die gleichen Sprachen zum Schreiben des gesamten Codes verwendet werden – C#, F#, Visual Basic. Das Schreiben von Code sollte für Sie eine sehr vertraute Erfahrung sein. .NET Core stellt jedoch einen neuen Stapel dar und ist keine Untermenge von .NET Framework. .NET Core und .NET Framework sollten als zwei Stapel betrachtet werden, die sich überschneiden und gemeinsam weiterentwickeln.

.NET Framework ist und bleibt der beim Schreiben von Desktopanwendungen für Windows 7 bis Windows 10 zu verwendende Stapel. Es ist sogar so, dass .NET Framework- und .NET Core-Code harmonisch in der gleichen Lösung koexistieren kann. Nehmen Sie z. B. ein Szenario an, in dem eine .NET Framework-GUI (etwa Windows Forms) in .NET Core geschriebene Dienste nutzt.

Es ist hilfreich, die Ähnlichkeiten und Unterschiede von .NET Core und .NET Framework unter zwei Sichtweisen zu betrachten: Funktionen des API Surface-Bereichs und der Laufzeit. Abbildung 1 zeigt die Überschneidung der APIs auf den beiden Plattformen.

.NET Framework und .NET Core verwenden eine Untermenge von APIs gemeinsam
Abbildung 1: .NET Framework und .NET Core verwenden eine Untermenge von APIs gemeinsam

.NET-APIs sind in .NET Core und .NET Framework implementiert (wenn auch manchmal mit unterschiedlichen zugrunde liegenden Implementierungen). .NET Core und .NET Framework weisen aber auch beide APIs und Funktionen auf, die das andere Produkt nicht besitzt. .NET Framework verfügt z. B. über mehrere GUI-Frameworks und Windows-spezifische APIs auf, die in .NET Core nicht vorhanden sind. Ebenso besitzt auch .NET Core plattformübergreifende Funktionen und APIs, die in .NET Framework fehlen.

Außerdem stellt .NET Framework eine Windows-Komponente dar, die mithilfe von Windows Updates gewartet wird. .NET Core verwendet ein völlig unterschiedliches Modell für die Speicherung und Wartung. .NET Core besteht aus NuGet-Paketen. Die Laufzeit ist lokal für die App installiert. Dies bedeutet, dass Anwendungen .NET Core „mit sich tragen“ können. Auf diese Weise können sie parallel mit anderen .NET Core-Instanzen auf einem Computer oder Gerät vorhanden sein. Die Wartung kann dann pro Anwendung und über einen Paket-Manager anstatt global über Updates des Betriebssystems erfolgen.

Hier eine Frage aus der Praxis: Wenn Sie etwas für einen Stapel schreiben, kann es auf dem anderen Stapel ausgeführt werden? Die Antwort auf diese Frage lautet wie die meisten Antworten im richtigen Leben: Es kommt darauf an. Wenn die verwendeten APIs auf beiden Plattformen implementiert sind, sollten Sie in der Lage sein, Ihren Code mit .NET Core und .NET Framework mit relativ wenig Aufwand Ihrerseits ausführen zu können. Wenn jedoch Abhängigkeiten in der ausgeführten Umgebung angenommen oder APIs verwendet werden, die in einem Stapel nicht verfügbar sind (z. B. eine Bibliothek zum Arbeiten mit auf XAML basierenden UIs), kann Ihr Code nicht stapelübergreifend ausgeführt werden. .NET Portability Analyzer – verfügbar als Befehlszeilentool (bit.ly/1Sd8oIK) oder Visual Studio-Extension (bit.ly/1LqX0aF) – ist ein Tool, das Ihre DLL-Dateien analysiert und einen Bericht zur Portabilität Ihres Codes aus .NET Framework in .NET Core generiert. In der Zukunft werden wir weitere Tools für die Portierung bereitstellen.

Die Befehlszeile: Ihr Einstiegspunkt für .NET Core

.NET Core enthält ein neues und überarbeitetes grundlegendes Toolset, das zum Entwickeln von Anwendungen verwendet wird. Dieses Toolset wird als .NET Core-CLI (Kurzform von „.NET Core Command-Line Interface“) bezeichnet. Wie andere Teile von .NET Core ist auch dieses Toolset eine Open Source-Anwendung (siehe GitHub.com/dotnet/cli) mit einer aktiven Open Source-Community, die intensiv in ihre Entwicklung eingebunden ist.

Für die Vorstellung eines neuen Toolsets gibt es gleich mehrere Gründe. Einerseits müssen Kernentwicklungsszenarien auf allen Plattformen unterstützt werden, die .NET Core unterstützt. Da die Plattformen sehr unterschiedlich sind, ist ein gutes Befehlszeilenverhalten eine hervorragende Grundlage, auf der aufgebaut werden kann. Schließlich ist die Befehlszeile standardmäßig auf allen Plattformen enthalten.

Als logische Erweiterung wollten wir die gleiche UX auf allen unterstützten Plattformen unterstützen. Sie können zwischen Linux, Windows und OS X wechseln, ohne den Umgang mit den Tools, ihre Syntax und die Semantik erneut erlernen zu müssen. Dieses Verhalten ist auf allen Plattformen identisch. Die Nutzungsmuster sind identisch, und selbst die Syntax ist identisch.

Das Konzept, dass ein Toolset verfügbar ist, das plattformübergreifend verwendet wird, gilt auch für Tools auf höherer Ebene: Visual Studio Code und Visual Studio. Diese Tools auf höherer Ebene setzen auf der .NET-CLI auf. Sie werden in Zukunft für die Unterstützung von .NET Core-Projekten verwendet. Dies bedeutet, dass beim Erstellen Ihrer .NET Core-Anwendung aus Visual Studio .NET-CLI-Tools aufgerufen werden, um den Buildvorgang auszuführen.

Testen der .NET Core-CLI

Als einfachsten Einstieg in die .NET Core-CLI befolgen Sie die Anleitungen im Handbuch „Erste Schritte“ (aka.ms/dotnetcoregs). Kurz gesagt: Sie laden einen Installer für Ihre Plattform herunter (oder registrieren einen neuen apt-get-Feed im Fall von Ubuntu), installieren die Tools und das war‘s schon. Die Installer übernehmen das Festlegen des Installationsordners für den Systempfad in allen unterstützten Betriebssystemen sowie aller anderen Umgebungsvariablen, die die CLI benötigt.

Anschließend können Sie beginnen, indem Sie den Treiber „dotnet“ aufrufen und einen Befehl übergeben (dies wird auch als „Verb“ bezeichnet). Der Treiber übernimmt die Ausführung des Befehls sowie das Übergeben von Argumenten an ihn. Zum Zeitpunkt der Erstellung dieses Dokuments enthielt das CLI-Paket die in Abbildung 2 aufgeführten Befehle. Wenn Sie diese Seite lesen, wurden ggf. bereits weitere Befehle hinzugefügt, die Ihre Produktivität steigern.

Abbildung 2: Einige allgemeine Befehle der .NET-CLI, die Sie zurzeit verwenden können

Befehl Beschreibung
dotnet new Initialisiert ein gültiges Projekt für eine Klassenbibliothek oder eine Konsolenanwendung mithilfe von C# als Sprache.
dotnet restore Stellt Abhängigkeiten wieder her, die in der Datei „project.json“ für ein bestimmtes Projekt definiert werden. Abhängigkeiten sind normalerweise NuGet-Pakete, die Sie in Ihrer Anwendung verwenden.
dotnet build Erstellt Ihren Code. Dieser Befehl erstellt eine IL-Binärdatei (Intermediate Language) für Ihr Projekt. Wenn es sich bei dem Projekt um eine Konsolenanwendung handelt, ist die generierte Ausgabe eine ausführbare Datei, die Sie sofort ausführen können. Standardmäßig gibt der Buildbefehl die erstellten Assemblys und ausführbaren Dateien (wenn zutreffend) an das Verzeichnis „bin“ in dem Verzeichnis aus, in dem er aufgerufen wurde.
dotnet test Jedes gute Tool sollte Unterstützung für das Ausführen von Tests enthalten. Dieser Befehl ermöglicht das Ausführen einer Sammlung von Tests mithilfe eines Runners, den Sie in der Datei „project.json“ angeben können. Zurzeit werden die xUnit- und NUnit-Testrunner unterstützt.
dotnet publish Veröffentlicht Ihre Anwendung für die Ausführung auf dem Zielcomputer.
dotnet pack Der Befehl „pack“ erstellt ein Paket für Ihr Projekt (als NuGet-Paket). Die Ausgabe ist eine Sammlung von NUPKG-Dateien, die Sie anschließend in Ihre Feeds hochladen oder im Vorgang „restore“ mithilfe der lokalen Ordnerüberschreibung verwenden können.
dotnet run Der Befehl „run“ kompiliert Ihre Anwendung und führt sie aus. Dieser Befehl kann als Analogie zu STRG +F5 betrachtet werden – nur ohne Visual Studio.

Sie können nicht nur die Befehle verwenden, die im Paket enthalten sind. Es besteht außerdem die Option, weitere Befehle als Tools in der Datei „project.json“ hinzuzufügen und diese dann wiederherzustellen. Das Paket wird als ein NuGet-Paket erstellt und bietet so ein praktisches Erweiterbarkeitsmodell, das einfach zu verwenden und zu verstehen ist.

Zusammenfassung

Wir hoffen, dass diese Informationen zu .NET Core hilfreich waren und Sie sich darauf freuen, .NET-Code zu schreiben, der plattformübergreifend ausgeführt werden kann. Als neuer Stapel bietet die Anwendung einige interessante Funktionen, die zuvor mit .NET Framework nicht möglich waren. Die .NET-CLI führt außerdem eine hervorragende Befehlszeilen-Benutzeroberfläche ein, die als Grundlage der Entwicklererfahrung dient und in andere Tools (z. B. Visual Studio und Visual Studio Code) integriert ist.

Schließlich wissen wir, dass Sie über zahlreiche Ressourcen verfügen, die für .NET Framework geschrieben wurden. Wir würden uns freuen, wenn diese Ressourcen zusammen mit der Weiterentwicklung von .NET Framework wachsen. Wir wünschen uns, dass .NET Framework und .NET Core zusammen in Systemen verwendet werden, die die Stärken beider Stapel nutzen.

Wenn Sie mehr erfahren oder sich ggf. beteiligen möchten, können Sie unter den folgenden Links die ersten Schritte ausführen:

Wir arbeiten an zahlreichen weiteren .NET Open Source-Projekten. Wenn Sie auch an diesen Projekten Interesse haben, besuchen Sie .NET Foundation, eine unabhängige Organisation, die die offene Entwicklung und Zusammenarbeit rund um .NET fördert. Microsoft hat mehrere Projekte in .NET Foundation beigetragen, ebenso wie andere Unternehmen (z. B. Xamarin, Umbraco, Salesforce und die .NET-Community). Weitere Informationen finden Sie unter DotNetFoundation.org/projects. Dort können Sie auch eigene Projekte beitragen.


Phillip Carterarbeitet als Program Manager im .NET-Team bei Microsoft. Carter liebt Systeme und Programmiersprachentheorien. Häufig diskutiert er Parallelitätsmodelle mit Freunden bis tief in die Nacht. Er hofft, dass eines Tages das Laufzeitverhalten aller Systeme in Typsystemen ausgedrückt werden kann und das logische Denken der Menschheit eine neue Ebene erreicht. Sie erreichen ihn unter phcart@microsoft.com.

Zlatko Knezevicarbeitet als Program Manager (PM) im .NET-Team bei Microsoft. Seit dem Jahr 2005 arbeitet er bei Microsoft, zuerst in CEE als Entwicklungs-Evangelist, dann als PM für SQL Server. In dieser Funktion hat er sich mit verschiedenen Dingen beschäftigt – vom Hinzufügen neuer Indizes im Kernmodul bis hin zum Erstellen von Butt-Diensten für Big Data, Data Discovery usw. Im Jahr 2015 stieß er als PM zum .NET-Team. Seitdem arbeitet er an plattformübergreifenden .NET Core-Benutzeroberflächen. Sie erreichen ihn unter Zlatko.Knezevic@microsoft.com..

Unser Dank gilt den folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Immo Landwerth und dem .NET Core- und Framework Program Management-Team