4Max/shutterstock.com

17. Februar 2017 / von Frank Mattauch

Quo

Vadis

.NET

Core

Der neue Kern

Microsoft hat mit .NET Core eine neue Version des .NET Frameworks herausgebracht, die großartige Erweiterungen und neue Möglichkeiten mit sich bringt. Dies wurde jedoch mit einer gewissen Inkompatibilität zu den Vorgängerversionen erkauft. Direkte Upgrade-Pfade existieren nicht und bei einem Umstieg ist mit Mehrkosten zu rechnen. Daher stellen Projektverantwortliche sich zurecht die Frage: „Was soll ich für mein Projekt in dieser Umbruchsphase nehmen?“ Besonders drängend wird diese Fragestellung, wenn in diesen Tagen des Umbruchs ein neues Projekt begonnen werden soll.

Fest steht bislang nur: Bei .NET Core ist Anfang Februar 2017 noch vieles in Bewegung und es finden aktuell noch grundlegende Umstellungen statt.

Microsoft Visual Studio 2017

Bis Visual Studio 2017 RC 2 gab es noch Projektdateien im JSON-Format. Dieser Ansatz wird jetzt doch nicht länger weiterverfolgt und die Projektdateien sind zurück auf das MSBuild-Format in XML umgestellt worden. Diese Umstellungen fanden in den .NET Core Tools statt. Auch jetzt kann sich das XML-Format der MSBuild-Dateien noch ändern. Zudem sind die Projektdateien aus Visual Studio 2017 inkompatibel zu denen aus Visual Studio 2015. In Visual Studio 2015 werden für .NET Core nur Projektdateien im JSON Format unterstützt. Teilweise treten dadurch irreführende Fehler beim Debuggen in Visual Studio 2015 auf, die aus den Projektdateien herrühren. Die Situation wird sich vermutlich erst bessern, wenn die .Net Core Tools offiziell veröffentlicht sind. [1]

Die Kommandozeile

Weitere Restrukturierungen betreffen die Kommandozeilenbefehle. Etliche Befehle wurden verändert und neue Befehle ersetzten die alten.

Wer Wert auf eine möglichst vollständige Dokumentation legt, wird aktuell noch enttäuscht. Beispielsweise wird die Dokumentation für die .NET Core Tools erst mit Visual Studio 2017 RTM in einer endgültigen Version zur Verfügung gestellt werden. Derzeit wird an dieser Dokumentation noch gearbeitet.

NuGet

Ebenfalls fehlen auch noch Migrationspfade für das Format des NuGet Package Managers. Die bislang üblichen Packages.config-Dateien können noch nicht in das neue PackageReference-Format konvertiert werden. Auch daran wird noch gearbeitet. Eine automatische Konvertierung wird es erst nach dem Release von Visual Studio 2017 geben. [2]

Diese Liste ist natürlich nur ein kleiner Auszug dessen was aktuell noch in Bewegung ist. Allerdings ist das auch nicht verwunderlich, weil aktuell ASP.NET Core, .Net Core SDK sowie die .Net Core Tools allerhöchstens Release Candidate-Status erreicht haben.

Das beutet allerdings nicht, dass mit .Net Core keine Anwendungen programmiert werden könnten: Ein Entwickler aus dem .Net Core-Team hat damit eine komplette Game Engine programmiert. Er musste dabei jedoch Wrapper für Libraries bauen, die noch nicht für .NET Core existieren. Einige Libraries mussten auch neu übersetzt werden, jedoch benötigte keiner der Bibliotheken eine komplizierte Neuentwicklung. [3]

Dies zeigt ein weiteres Problem von .NET Core auf: Die Verfügbarkeit von kompatiblen Drittanbieter-Bibliotheken ist aktuell noch nicht umfassend gegeben. Microsoft plant offensichtlich alles mit dem Release von Visual Studio 2017 in einer finalen Version bereitzustellen. Aktuell wird in der Presse von einem Release-Termin im Mai gemutmaßt. [4]

Fazit

Welches Vorgehen ist daher sinnvoll, wenn noch vor der offiziellen Freigabe von Microsoft Visual Studio 2017 ein neues Projekt begonnen werden soll?

  • Der Einsatz von .NET Core birgt noch Risiken, aber auch Chancen. Wer einen straffen Zeitplan hat und es sich nicht erlauben kann, mit Technologie zu spielen, der sollte auf den offiziellen Release von Visual Studio 2017 warten. Selbst danach wird es noch Probleme mit der Verfügbarkeit und Dokumentation von Bibliotheken geben, die auf .NET Core aufbauen.
  • Projekte mit kurzer Entwicklungszeit sollten aus diesem Grund bei einer stabilen .NET-Version bleiben (4.5/4.6.2), um die Risiken zu vermeiden.
  • Bei Großprojekten hingegen lohnt sich der Sprung auf ein zukunftssicheres Framework. Es muss ein Budget für Startschwierigkeiten durch beispielweise fehlende Bibliotheken, für Schulungen und für Experimente mit .NET Core eingeplant werden. Dafür entfallen die Kosten für einen späteren Migrationsaufwand.
  • In bereits existierenden, langlebigen Projekten sind Migrationsaufwände unvermeidbar. Vor der Migration sollte sichergestellt werden, dass alle verwendeten Bibliotheken und Technologien in .NET Core bereits komplett verfügbar sind.
  • Web-Projekte, die auf ASP.NET Core basieren sollen, laufen bereits auch auf dem .NET Framework 4.6.2. Auch wenn hier noch möglicherweise kleinere Änderungen zu erwarten sind, scheint die Migration auf .NET Core dort deutlich risikoärmer.

Autor

Weitere Artikel

Das könnte Sie auch interessieren