16. Mär 2017
Lesedauer 13 Min.
Alles in einem Paket
Werkzeuge für .NET Core
Unterstützt Visual Studio .NET Core, oder müssen Entwickler auf die Konsole wechseln?
Bild: Shutterstock / agsandrew
Das jüngste Mitglied der Frameworks der .NET-Familie hat Microsoft von Grund auf neu entwickelt, um es leichtgewichtig und plattformübergreifend einsetzbar zu machen. Und tatsächlich läuft .NET Core sowohl unter Windows als auch auf Linux- und Mac-Systemen. Selbst auf Mini-Computern mit ARM-Prozessoren – wie dem Raspberry Pi – ließ sich .NET Core schon zum Laufen bringen [1]. Es werden mehrere Linux-Distributionen genannt, für die .NET Core zur Nutzung bereitgestellt wird..NET Core wurde in erster Line für Web- oder Dienstanwendungen entwickelt, die auf einem Server laufen, mit dem Fokus auf Microsofts Cloud-Plattform Azure. Das ASP.NET-Team war maßgeblich an der Entwicklung von .NET Core beteiligt. Aber nicht nur ASP.NET-Anwendungen werden mit .NET Core entwickelt; auch mit C# entwickelte Apps, die auf der Universal-Windows-Plattform laufen, nutzen inzwischen .NET Core.Was genau macht die Core-Variante so leichtgewichtig? .NET Core ist kein Framework im klassischen Sinne, das in einem großen monolithischen Paket daherkommt, wie das „große“ .NET Framework. Es basiert vielmehr auf vielen NuGet-Paketen und wird auch über NuGet zur Verfügung gestellt. Dabei wird es für die jeweilige Anwendung individuell zusammengestellt: Jede App nimmt sich genau das aus dem Framework, was sie tatsächlich benötigt, und liefert das auch mit aus. Dadurch wird das publizierte Paket zwar größer, aber die Software ist nicht mehr abhängig von einem global installierten Framework und dessen Version.Weiter wird die .NET-Core-Laufzeitumgebung mit ausgeliefert. Auch das ist wichtig, um nicht von einem globalen Framework abhängig zu sein.
.NET Core SDK Preview 2
Die Werkzeuge für .NET Core waren, als dieser Artikel entstand, noch im Preview-Stadium. Sie funktionieren, sind aber noch nicht offiziell; es können sich daher noch Änderungen ergeben. Zudem gibt es auch noch ein Versionsproblem beim Download der SDKs: Auf der offiziellen Download-Seite steht die Preview 2 für Visual Studio 2015 bereit, sowie der RC 3 für Visual Studio 2017. Installiert man aber die jüngste RC-Version von Visual Studio 2017, erhält man die Preview 4 von .NET Core.Vor einem Blick auf die Unterstützung in Visual Studio soll ein Blick unter die Haube zeigen, was die Werkzeuge überhaupt tun. Das .NET Core SDK gibt es für Linux, Mac und Windows [2], unter Windows direkt mit der Unterstützung für Visual Studio 2015 und Visual Studio 2017. Dieser Abschnitt beschäftigt sich mit dem SDK in der Preview 2, das bis dato für Visual Studio 2015 zur Verfügung steht.Wenn das SDK für die vorliegende Plattform eingerichtet ist, lässt es sich in der Konsole prüfen. Tippen Sie dort dotnet ein. Es sollte sich eine Ausgabe ähnlich wie in Bild 1 zeigen.
Die Konsole kann nun geöffnet bleiben, um das .NET Core SDK in Aktion zu erleben. Eine neue lauffähige Applikation lässt sich in wenigen Minuten mit folgenden Schritten erstellen:
mkdir dotnet-test
cd dotnet-test
dotnet new
Der Ordner enthält nur zwei Dateien: eine Datei namens Program.cs mit dem Programmcode, und die Datei project.json mit Einstellungen und NuGet-Referenzen.Nun geben Sie die folgenden Befehle ein:
dotnet restore
dotnet build
Der erste Befehl stellt die benötigten NuGet-Pakete zusammen, der zweite baut die Applikation. Das Verzeichnis enthält nun einen bin- und einen obj-Ordner sowie die Datei project.lock.json. Letztere beschreibt, welche NuGet-Pakete mit welchen Abhängigkeiten benötigt werden.Um die Applikation laufen zu lassen, tippen Sie folgenden Befehl ein:
dotnet run
Sie sehen die Ausgabe Hello World! in der Konsole (Bild 2). Das Programm ist fertig und kann veröffentlicht werden:
dotnet publish
Dieses Kommando erzeugt im bin-Projektverzeichnis einen neuen Ordner mit den nötigen Dateien.
Alle diese Kommandos haben noch weitere Optionen, mit denen sich Zielplattform, Konfiguration, Runtime et cetera einstellen lassen. Mit folgenden Aufrufen können Sie die entsprechende Hilfe in der Konsole aufrufen:
dotnet --help
dotnet <command> --help
Diese Befehle sind auf jeder Plattform verfügbar und können in jeder Konsole, jedem Terminal und jeder Bash-Shell ausgeführt werden.Der Befehl dotnet new kann nicht nur Konsolenapplikationen erstellen, sondern auch Webanwendungen. Mit der Option Type können Konsolen-, Web-, Bibliotheks- und Testprojekte erzeugt werden; die Typangaben dafür lauten console, web, lib und xunittest, wenn sie in C# erstellt werden. Über Language Option können Sie auch F# auswählen. Dann stehen allerdings nur die Typen console und lib zur Verfügung.Das Kommando dotnet new entspricht also dem Menüpunkt Datei | Projekt | Neu ... und dem entsprechenden Dialog in Visual Studio.
Visual Studio Code
Ebenfalls neu in der Open-Source-Familie von Microsoft ist Visual Studio Code, kurz VS Code. Dieser Code-Editor ist in derselben Klasse einzuordnen wie Atom von GitHub oder Brackets von Adobe. VS Code ist ein in JavaScript entwickelter Texteditor, der viele verschiedene Sprachen unterstützt und sich über Plug-ins erweitern lässt. Entwickelt wird er von Microsoft in der Schweiz unter Erich Gamma, daher wird er auch gern als das „Swiss Army Knife“ unter den Code-Editoren bezeichnet.Mit VS Code lassen sich keine Projekte wie im großen Visual Studio erstellen. Allerdings kann der Editor verwendet werden, um die oben erstellte Konsolenanwendung zu öffnen und zu bearbeiten. Ist VS Code eingerichtet, steht der Befehl code zur Verfügung. Sollte die Konsole vom obigen Beispiel noch geöffnet und auf den Ordner der Applikation eingestellt sein, so probieren Sie einmal folgenden Befehl (inklusive des Punktes):code .
Dies öffnet das aktuelle Verzeichnis in VS Code (Bild 3). Der Editor könnte nun fragen, ob die Unterstützung für C# installiert oder aktualisiert werden soll, falls das noch nicht passiert ist. Der Editor erkennt auch die Datei project.json und erkundigt sich unter Umständen, ob alle NuGet-Pakete installiert werden sollen, falls er sie nicht findet. Danach ist die komplette Unterstützung für C# verfügbar und Sie können die App auch mit der Taste [F5] debuggen (Bild 4).
Visual Studio Code kann noch viel mehr, unter anderem unterstützt es auch weitere Technologien wie Node.js. Dies zu erläutern bedürfte aber eines weiteren, eigenen Artikels.
nen, muss das entsprechende SDK installiert sein, das neue Projektvorlagen zur Auswahl stellt, und zwar für Klassenbibliotheken (Class Library (.NET Core)), Konsolenanwendungen (Console Application (.NET Core)) und Webprojekte (ASP.NET Core Web Application (.NET Core)), wie es in Bild 5 zu sehen ist.
Heute und in Zukunft
Die Datei project.json enthält alle für das Projekt entscheidenden Angaben wie die Version, nötige NuGet-Referenzen, Tools und Zielplattformen. Microsoft hat hier versucht, eine offene Projektstruktur zu schaffen, wie es von anderen Technologien wie etwa Node.js bekannt ist. project.json entspricht weitgehend der Datei package.json aus Node.js. Das Prinzip ist sehr flexibel und macht die Entwicklung einfach und schnell.Als .NET Core und ASP.NET Core entstanden, war allerdings noch nicht klar, dass Microsoft Xamarin kaufen und somit ein weiteres Framework zur Produktpalette hinzukommen würde. Microsoft musste das Konzept deshalb noch einmal überarbeiten, um eine einheitliche Projekt- und Build-Konfiguration zur Verfügung zu stellen.Das heißt: project.json wird wieder verschwinden und durch die klassische Projektdatei (.csproj) ersetzt. Microsoft hat aber sein Versprechen gehalten, die Vorteile von project.json in die Projekt-Dateien zu übertragen. So lassen sich nun Dateien per Suchmuster im Projekt registrieren, anstatt wie bisher alle Dateien einzeln angeben zu müssen. Speziell für ASP.NET-Core-Projekte, in denen sehr viele automatisch erzeugte Dateien im Spiel sein können, ist das ein großer Vorteil. Denn bisher baute und publizierte Visual Studio nur Dateien, die auch in der Projektdatei berücksichtigt waren.Hier werden .NET-Core-Projekte mit Visual Studio 2015 und 2017 RC betrachtet. Erstere basieren auf der Datei project.json. Visual Studio 2017 ist als Release Candidate verfügbar und kann frei heruntergeladen und getestet werden [3]..NET Core und Visual Studio 2015
Um .NET Core mit Visual Studio nutzen zu kön-nen, muss das entsprechende SDK installiert sein, das neue Projektvorlagen zur Auswahl stellt, und zwar für Klassenbibliotheken (Class Library (.NET Core)), Konsolenanwendungen (Console Application (.NET Core)) und Webprojekte (ASP.NET Core Web Application (.NET Core)), wie es in Bild 5 zu sehen ist.
Zum Vergleich mit den obigen Beispielen soll nun eine neue Konsolenanwendung erstellt werden. Ein Blick in den Ordner des neu erstellten Projekts verrät, dass es diesmal in der von Visual Studio bekannten Projektmappen-Struktur bereitgestellt ist. Es gibt eine .sln-Datei sowie Unterordner für das eigentliche Projekt. Im eigentlichen Projektverzeichnis befinden sich die bekannten Dateien Programm.cs und project.json. Ebenso bereits vorhanden ist project.lock.json, was darauf hindeutet, dass das Kommando dotnet restore bereits von Visual Studio ausgeführt wurde.Im Ordner befindet sich auch eine Projektdatei mit der Endung .xproj. Diese Art Projektdatei wird es – ebenso wie die project.json – in Zukunft nicht mehr geben. Beide werden durch die klassischen .csproj-Datei ersetzt werden. Weiterhin gibt es einen Properties-Ordner, der die bekannte AssemblyInfo.cs enthält.Auf den ersten Blick sieht dieses Projekt also wie eine klassische Konsolenapplikation aus. Lediglich die Datei project.json, die es in klassischen Projekten nicht gibt, ist hinzugekommen. Blickt man aber in die Eigenschaften des Projekts, sind nur eingeschränkte Möglichkeiten zu sehen. In den Anwendungseinstellungen lässt sich lediglich der voreingestellte Namensraum ändern. Auch unter Build sind nur wenige Parameter zu verändern. Lediglich die Debug-Einstellungen sind etwas interessanter: Neben den üblichen Argumenten und dem Arbeitsverzeichnis können hier Umgebungsvariablen definiert werden, die der Anwendung im Debug-Modus zur Verfügung stehen sollen.Projekte, die mit Visual Studio erstellt werden, sind mit denen, die über die Konsole erzeugt werden, kompatibel; Visual Studio benötigt keine Projektdatei, um ein Projekt zu öffnen. project.json genügt als Projektdatei. Visual Studio erstellt dann beim Öffnen automatisch eine .xproj-Datei. Umgekehrt lässt sich auch ein mit Visual Studio erstelltes Projekt über die .NET-Konsole mit dem Kommando dotnet run ausführen. In seltenen Fällen ist es sogar nötig, mit dem Kommando dotnet restore die NuGet-Pakete über die Konsole zu laden, weil die .NET-Core-Erweiterung für Visual Studio 2015 derzeit noch nicht fertig ist und die .NET-Kommandozeile aber besser funktioniert. Debugging ist – wie in Visual Studio Code – kein Problem und funktioniert auf Anhieb.
Referenzen
Das Setzen von Verweisen ist ein spezielles Thema. Da .NET-Core-Projekte bisher komplett auf NuGet basieren, müssen auch eingebundene externe Projekte ein NuGet-Paket sein. Dazu sollten Sie sich einmal ansehen, wie die bisherigen Verweise aussehen. Dazu öffnet man am besten die Datei project.json und parallel dazu im Projektmappen-Explorer die Ansicht für die Referenzen (Bild 6).
project.json enthält nur einen Verweis auf ein Paket mit dem Namen Microsoft.NETCore.App. Dieses Paket dient als eine Art Container, der weitere rund 40 Pakete einbindet. Diese wiederum haben ihre eigenen Abhängigkeiten und so weiter. Über Microsoft.NETCore.App werden alle Abhängigkeiten geladen, die für eine Applikation benötigt werden. Tatsächlich sind es ein paar mehr, mit dabei sind auch die Laufzeitumgebung, der Compiler et cetera.Wenn aber alles auf NuGet basiert – können dann .NET-Core-Assemblies eingebunden werden? Ja, aber nur, wenn diese in ein NuGet-Paket verpackt sind. Andernfalls erscheint beim Versuch, den Verweis zu setzen, ein in die Irre führender Fehler: „.NET Core projects only support referencing .NET framework assemblies in this release. To reference other assemblies, they need to be included in a NuGet package and reference that package.”Irreführend ist er deshalb, weil .NET-Core-Projekte eigentlich auch nur .NET-Core-Assemblies referenzieren können. Assemblies des klassischen .NET Framework sind logischerweise vom klassischen .NET Framework abhängig, das hier aber nicht funktioniert.Und wie verhält es sich mit Verweisen auf andere Projekte? Das ist schnell ausprobiert. Dazu wird ein neues Projekt mit dem Namen DotnetTestVs.Library als Klassenbibliothek angelegt. Es enthält als einzige Referenz einen Verweis auf die NETStandard.Library 1.6, die wie das Paket Microsoft.NETCore.App eine Container-Assembly ist, die alle nötigen Bibliotheken in das Projekt holt.Die Standard-Bibliothek ist frei zu verwenden und kann wie gewohnt als Projektreferenz eingebunden werden. Hier muss kein NuGet-Paket erstellt werden, das passiert automatisch beim Publizieren des Projekts. Es genügt, dass die project.json-Datei des referenzierten Projekts erreichbar ist, am besten in einem Ordner, der auf gleicher Ebene wie der Ordner des zu referenzierenden Projekts liegt.
Bild 7 zeigt, was Visual Studio 2015 dazu im Hintergrund erledigt hat. Es hat einen Eintrag in project.json eingefügt, als handle es sich um einen NuGet-Verweis. Das funktioniert, weil eine passende project.json gesucht wird. Findet die IDE keine, so sucht sie ein passendes Paket bei NuGet.
ne systemspezifischen Abhängigkeiten haben. So läuft eine Bibliothek nicht unter Xamarin, wenn in ihr eine Abhängigkeit zur Windows-Registry besteht. Ebenso kann eine App unter .NET Core nichts mit einem Xamarin-spezifischen API anfangen.Der .NET-Standard bringt Ordnung in die Frameworks und Plattformen von Microsoft. Bibliotheken, die ihn unterstützen, können tatsächlich plattformübergreifend sein.Die Frameworks werden einen spezifischen .NET-Standard implementieren: .NET Core 1.0 den Standard 1.6 und .NET Core 1.2 sowie .NET 4.6.2 den .NET-Standard 2.0. .NET Core 1.2 wird demnach eine ganze Menge weiterer Merkmale enthalten als bisher. Microsoft spricht von einer Verdoppelung der APIs und darüber hinaus. Genauer: von 13.501 APIs, die auf 32.638 APIs aufgestockt werden. Das ist eine gute Nachricht für .NET-Core-Entwickler, denn diese Plattform wird eine bessere Unterstützung für Serialisierung, Netzwerkfunktionen, I/O, Threading und einiges mehr bekommen. Dabei werden Bibliotheken, die für .NET-Standard 1.x geschrieben wurden, kompatibel zu 2.0 bleiben, da nur APIs hinzugefügt, aber keine entfernt werden (siehe Bild 8). .NET-Standard 2.0 wird alle APIs der vorherigen Versionen enthalten.
Alles wieder wie vorher
Wie bereits angedeutet, fallen project.json und die .xproj-Datei künftig weg und werden von der klassischen .csproj-Datei ersetzt, ergänzt um die Vorteile der project.json. Das heißt aber auch, dass in Zukunft wie gewohnt andere Projekte, Assemblies und NuGet-Pakete eingebunden werden können. Das wird der Fall sein, da die Tools nicht mehr unbedingt auf das jeweilige Framework (.NET Framework, .NET Core oder Xamarin) werden Rücksicht nehmen müssen, sondern nur darauf zu achten haben, ob das zu referenzierende Objekt den .NET-Standard unterstützt, den das jeweilige Projekt unterstützt. So wird es möglich sein, dass eine .NET-Core-Assembly eine .NET-Framework-Assembly referenzieren kann, die zum Beispiel den .NET-Standard der Version 2.0 implementiert. Um plattformunabhängig zu bleiben, ist es nur wichtig, dass die zu referenzierende Bibliothek keine weiteren systemspezifischen Abhängigkeiten enthält.Der .NET-Standard
Wie in Bild 7 zu sehen ist, verweist die neu erstellte Bibliothek auf ein NuGet-Paket mit Namen NETStandard.Library (1.6.0). Diese Version ist derzeit die aktuelle, die zusammen mit .NET Core 1.0 im Sommer 2016 veröffentlicht wurde. .NET Core 1.0 ist allerdings das einzige Framework, das diese Version unterstützt. .NET Core wird schneller veröffentlicht und Vorreiter bei neuen Implementierungen sein. Neue .NET-Merkmale werden in Zukunft also zuerst in .NET Core erscheinen und erst später in das .NET Framework übernommen und dann mit einem Windows-Update auf dem Rechner landen.Bei diesem .NET-Standard handelt es sich im Grunde genommen nur um die Spezifikation einer Schnittstelle für Plattformen wie .NET Core, .NET Framework und Xamarin. Bibliotheken, die sie unterstützen, sind untereinander kompatibel, egal auf welchem System sie laufen. Die Voraussetzung ist, dass die Bibliotheken kei-ne systemspezifischen Abhängigkeiten haben. So läuft eine Bibliothek nicht unter Xamarin, wenn in ihr eine Abhängigkeit zur Windows-Registry besteht. Ebenso kann eine App unter .NET Core nichts mit einem Xamarin-spezifischen API anfangen.Der .NET-Standard bringt Ordnung in die Frameworks und Plattformen von Microsoft. Bibliotheken, die ihn unterstützen, können tatsächlich plattformübergreifend sein.Die Frameworks werden einen spezifischen .NET-Standard implementieren: .NET Core 1.0 den Standard 1.6 und .NET Core 1.2 sowie .NET 4.6.2 den .NET-Standard 2.0. .NET Core 1.2 wird demnach eine ganze Menge weiterer Merkmale enthalten als bisher. Microsoft spricht von einer Verdoppelung der APIs und darüber hinaus. Genauer: von 13.501 APIs, die auf 32.638 APIs aufgestockt werden. Das ist eine gute Nachricht für .NET-Core-Entwickler, denn diese Plattform wird eine bessere Unterstützung für Serialisierung, Netzwerkfunktionen, I/O, Threading und einiges mehr bekommen. Dabei werden Bibliotheken, die für .NET-Standard 1.x geschrieben wurden, kompatibel zu 2.0 bleiben, da nur APIs hinzugefügt, aber keine entfernt werden (siehe Bild 8). .NET-Standard 2.0 wird alle APIs der vorherigen Versionen enthalten.
.NET Core und Visual Studio 2017
Wie erwähnt, war Visual Studio 2017 als Release Candidate frei zum Testen verfügbar, als dieser Artikel entstand. In dieser Form enthält es das .NET Core SDK als Preview 4. Die IDE unterstützt daher das zukünftige .NET Core mit der .csproj-Datei.Zum Vergleich mit dem bisherigen Verfahren können Sie ebenfalls eine Konsolenapplikation anlegen. In Bild 9 ist zu sehen, dass das Projekt nun wesentlich aufgeräumter wirkt. Die Datei project.json fehlt ebenso wie project.json.lock, und aus der .xproj-Datei ist nun eine .csproj-Datei geworden.
Auch die Projekteigenschaften (siehe Bild 10) ähneln jetzt mehr einem klassischen Projekt. Das macht den Umstieg für Entwickler wesentlich einfacher.
Wirklich interessant ist allerdings der Quelltext der Projektdatei. Ein Beispiel:
<Project Sdk="Microsoft.NET.Sdk"
ToolsVersion="15.0">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.0
</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Compile Include="**\*.cs" />
<EmbeddedResource Include="**\*.resx" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NETCore.App"
Version="1.0.1" />
</ItemGroup>
</Project>
Trotz einiger Verweise, die im Projektmappen-Explorer zu sehen sind, findet sich in der Projektdatei nur eine Referenz. Ebenso gibt es zwei Einträge, um Dateien einzubinden. Sowohl Ressourcen- als auch C#-Dateien werden über Platzhalter in das Projekt eingebunden. Auf diese Art lassen sich alle C#-Dateien pauschal referenzieren. Automatisch erzeugte Dateien werden auch automatisch erkannt. Außerdem führt das neue System dazu, dass die Projektdatei kleiner und übersichtlicher wird. Gleiches gilt für die NuGet-Referenzen. Das macht es einfacher, die Projektdatei von Hand zu bearbeiten. Tatsächlich ist vorgesehen, dass die Projektdateien manuell editiert werden können. Daher gibt es nun im Kontextmenü der Projektmappe eine Auswahl, um die Projektdatei in Visual Studio direkt zu bearbeiten, ohne dass das Projekt erst entladen werden muss. Die Einfachheit der project.json wurde also tatsächlich in die klassische Projektdatei übernommen.Öffnet Visual Studio 2017 ein Projekt, das mit einer älteren IDE-Version erstellt wurde, wandelt es dieses automatisch um. Die IDE fasst die Einstellungen aus der .xproj-Datei und aus projekt.json in der neuen .csproj-Datei zusammen.Bereits umgewandelte Projekte lassen sich allerdings nicht mehr mit der alten IDE bearbeiten. Eine Sicherung ist hier also sinnvoll für den Fall, dass es mit der RC-Version von Visual Studio 2017 Probleme geben sollte.
.NET Core SDK Preview 4
Die Preview 4 des .NET Core SDK unterstützt bereits die neue Projektstruktur, ist etwas umfangreicher und bietet neue Projektvorlagen. Ein Aufruf von dotnet -help zeigt mehr Möglichkeiten als in den vorherigen Versionen. Über den Aufruf dotnet new lassen sich nun zusätzlich MSTest-Projekte erstellen, und alle Projekte enthalten die neue .csproj-Datei. Diese sind übrigens nicht mehr mit Visual Studio 2015 kompatibel, da sie ein jüngeres MSBuild-Schema unterstützen.Fazit
Microsoft hat mit .NET Core ein neues Framework bereitgestellt, das viele neue Möglichkeiten und Einsatzbereiche unterstützt. Unter Windows entwickeln und auf Linux bereitstellen war bis dahin nicht so ohne Weiteres möglich. Ein Webentwicklungsteam, das eine ASP.NET-Applikation sowohl unter Linux, macOS und Windows entwickeln kann, um später auf Azure zu publizieren, war früher undenkbar. .NET Core ist selbst in der Amazon-Cloud und auf kleinen IoT-Geräten machbar. Das schafft ungeahnte Freiheiten für die Entwickler, aber auch für die Software selbst und ist ein großer Schritt in die richtige Richtung.Microsoft macht es so einfach wie möglich. VS-Entwickler werden sich nicht umgewöhnen müssen. .NET-Core-Projekte werden sich so entwickeln lassen wie herkömmliche Projekte. Selbst die Zielplattform muss weniger stark beachtet werden, wenn man sich an den .NET-Standard hält.Fussnoten
- Thread „Visual Studio Code & .Net Core ARM support“, http://www.dotnetpro.de/SL1704VSTooling1
- .NET, https://dot.net
- Visual Studio Download,, http://www.dotnetpro.de/SL1704VSTooling2
