.NET 2015 umfasst .NET Framework 4.6 und .NET Core 5.0

Zwei auf einen Streich: .Net 2015
Kommentare

Erstmals erscheinen in diesem Jahr zwei neue .NET-Versionen: Eine Aktualisierung von .NET Framework 4.5.2 unter dem Namen .NET Framework 4.6 sowie ein völlig neu gestaltetes, modulares .NET Core Framework 5.0. Als Oberbegriff verwendet Microsoft „.NET 2015“. Dieser Beitrag gibt einen Überblick über die Neuerungen in beiden Teilen von .NET 2015.

Eine grafische Darstellung der neuen Welt gibt es in Abbildung 1: Rechts sieht man in Gelb das .NET Framework 4.6, das – wie die Vorgängerversionen 4.5, 4.5.1 und 4.5.2 – ein Inplace-Update ist. Auf einem System vorhandene Versionen von .NET 4.x (also 4.0, 4.5, 4.5.1 und 4.5.2) werden durch .NET 4.6 überschrieben, das in Windows 10 ausgeliefert wird. Als kostenfreies Add-on ist es verfügbar für Windows Vista Service Pack 2, Windows 7 Service Pack 1, Windows 8, Windows 8.1, Windows Server 2008 R2 SP1; Windows Server 2008 Service Pack 2, Windows Server 2012 und Windows Server 2012 R2.

.NET Framework 4.6 soll voll kompatibel sein zu .NET 4.5.2, d. h. alle Arten von .NET-Anwendungen (Konsole, Windows Forms, WPF, Windows-Dienste, ASP.NET Webforms, ASP.NET MVC, ASP.NET Web Pages usw.) laufen hier weiterhin. Das „soll“ an dieser Stelle drückt aus, dass .NET 4.6 zum Zeitpunkt der Abfassung dieses Beitrags noch nicht in der RTM-Version erschienen ist und von daher diese von Microsoft verkündete vollständige Kompatibilität noch nicht getestet werden konnte. In den dem Autor zur Verfügung stehenden Vorabversionen gab es allerdings keinerlei Kompatibilitätsprobleme beim Test mit einigen produktiven Desktop- und Webanwendungen. Zum Erscheinungszeitpunkt des Beitrags hingegen wird eine RTM-Version von .NET 4.6 vorliegen, da dieses zum Erscheinen von Windows 10 am 29.7. fertig sein muss.

Reduziert auf den Kern

Links in Abbildung 1 sieht man das neue .NET Core 5.0. Anders als .NET Framework 4.6, das weiterhin nur auf Windows läuft, liefert Microsoft das .NET Core 5.0 auch für Linux und Mac OS. Durch die Microsoft Intermediate Language und den Just-in-Time-Compiler ist das .NET Framework seit der Version 1.0 von seinen Grundzügen her plattformunabhängig. Allerdings hat Microsoft zuvor niemals ernsthafte Implementierungen für andere Betriebssysteme ausgeliefert. Die 2002 erschienene „Shared Source Common Language Infrastructure“ (Alias „Rotor“) war neben Windows XP zwar für Mac OS und FreeBSD verfügbar, jedoch enthielt sie nur die bei der ECMA und ISO standardisierten Basisklassen von .NET, allerdings keine Oberflächentechniken und keine Datenzugriffstechniken.

.NET Core hat seinen Namen aber nicht aufgrund der Plattformunabhängigkeit, sondern weil es ein modulares .NET Framework mit vergleichsweise kleinem Kern (nur ca. 14 MB) und zahlreichen Zusatzbibliotheken ist. Umgangssprachlich grenzt Microsoft das bisherige .NET Framework mit .NET „Full“ Framework, .NET „Desktop“ Framework und auch .NET „Classic“ Framework von .NET Core 5.0 ab, für das auch die Namen „Cloud-optimized Framework“ und „Modular .NET Framework“ im Umlauf sind.

Sowohl der Kern als auch die Zusatzbibliotheken sind NuGet-Pakete (Abb. 2). Microsoft nimmt hier ein komplettes Refactoring der Implementierung vor, wobei die von den Entwicklern nutzbaren APIs in vielen (aber nicht allen) Fällen gleich bleiben.

Wie stark Microsoft modularisiert, zeigt Abbildung 3: Die Klassen des Namensraums System.IO, die bisher komplett in der mscorlib.dll steckten, sind nun auf 11 (sic!) Assemblies (und NuGet-Pakete) aufgeteilt. Die Idee dahinter ist: Man sollte nur die Klassen in sein Projekt binden und zur Laufzeit in den Arbeitsspeicher RAM laden, die man wirklich braucht. Zum Beispiel: Die Klasse System.IO.FileSystemWatcher benutzen eher wenige Entwickler. Das zugehörige NuGet-Paket System.IO.FileSystem.Watcher besteht nur aus ganz wenigen Klassen. Neben der FileSystemWatcher-Klasse sind das nur Klassen für die Ereignisparameter der Dateisystemüberwachung. Auch das Paket System.IO.FileSystem.DriveInfo besteht aus lediglich drei öffentlichen Klassen: System.IO.DriveInfo, System.IO.DriveType und System.IO.DriveNotFoundException. Dabei fällt auf, dass Paketname und Namensraum abweichen. Der Namensraum der IO-Klassen ist wie bisher System.IO. Bei den Paketnamen hat Microsoft noch FileSystem angehängt. In Abbildung 1 sieht man exemplarisch nur wenige der vielen NuGet-Pakete in den Kästen „.NET Core 5.0“ und „ASP.NET 5.0“.

Aber nicht alle bisherigen, mehr als 13 000 .NET-Klassen gibt es nun in .NET Core 5.0. Microsoft trifft eine „nutzungsabhängige Auswahl“ und hat dazu in der Vergangenheit (mit Zustimmung der Entwickler) Daten über die Nutzung von .NET-Klassen gesammelt. In .NET Core 5.0 wird es im ersten Schritt nur etwa 10 Prozent der Klassen geben, die es derzeit in .NET 4.6 gibt. Und es wird dort wohl auch niemals alle bisherigen .NET-Klassen geben. Einige Techniken, die älter sind als Windows Forms und ASP.NET Webforms, werden sicher nicht auf .NET Core portiert. Auch das ADO.NET-DataSet gibt es hier nicht. Für den Datenzugriff in .NET Core gibt es noch DataReader und Command-Objekte sowie das ADO.NET Entity Framework 7. Immo Landwert aus dem .NET-Framework-Team kommentiert das folgendermaßen: „We generally consider DataSet and friends (DataTable, DataView, TableAdapter) legacy. However, that doesn’t necessarily mean that those APIs will never be available on .NET Core as we generally do support legacy APIs if they important for porting scenarios“.

Wie Abbildung 1 zeigt, gibt es in .NET Core zunächst lediglich zwei Anwendungsarten. Ganz im Sinne der von Satya Nadella verkündeten Microsoft-Strategie „Mobile first, Cloud first“ gibt es für .NET Core nun allein die beiden Anwendungsmodelle „Windows 10 Universal Apps“ und ASP.NET 5.0, wobei ASP.NET 5.0 lediglich ASP.NET MVC 6.0 inklusive WebAPI sowie ASP.NET WebPages 6.0 umfasst. ASP.NET MVC und ASP.NET WebAPI sind hier zu einem einzigen Framework verheiratet. Microsoft will zukünftig nur noch von MVC sprechen. Hier kommt es leider zu verschiedenen Versionsnummern, da Microsoft die bisherigen Versionsnummern weiterzählt. ASP.NET insgesamt war ja bekanntlich bereits bei Version 4.5.x und MVC schon bis Version 5.2.x vorgerückt. WebAPI, das bisher bei Version 2.2 war, geht in MVC 6 auf.

.NET-basierte Windows-10-Universal-Apps nutzen neben den .NET- Core-Klassen auch weiterhin die Windows Runtime Library (WinRT) für XAML-Oberflächen sowie den Zugriff auf das Betriebssystem. Bei den Windows-10-Apps gibt es aber noch eine Besonderheit: Sie verwenden bei Auslieferung über den Windows Store nicht die .NET Core CLR, sondern die .NET Native CLR. Die .NET Native CLR basiert komplett auf Native Code, und auch die Windows-10-Universal-Apps werden nicht in Intermediate Language, sondern als Native Code ausgeliefert. Zwar erzeugen die Sprachcompiler weiterhin Intermediate Language, diese wird dann aber schon vor der Auslieferung im Windows Store in Native Code umgewandelt. Das erinnert an das schon lange bekannte ngen-Verfahren, doch .NET Native arbeitet ganz anders und ist im Resultat deutlich schneller als eine mit ngen behandelte Assembly. Bei .NET Native ziehen die Werkzeuge nur den tatsächlich benötigten Programmcode aus den Assemblies der .NET-Framework-Klassen und optimieren ihn zusammen mit dem jeweils eigenen Programmcode des Entwicklers in einer einzigen Assembly. Für diese Optimierung kommt das NUTC-Backend des Microsoft-C++-Compilers zum Einsatz. .NET-Native-Anwendungen starten sehr viel schneller, weil die Just-in-Time-Kompilierung und das Laden referenzierter Assemblies entfällt. Und sie brauchen durch die Optimierung auch weniger RAM. Sicherlich würden viele Entwickler von WPF-Anwendungen dieses Verfahren auch sehr gerne nutzen. Microsoft hat dazu bisher jedoch lediglich angekündigt, dass man diesen Weg für WPF ebenfalls in Erwägung zieht – eine konkrete Realisierung für die Öffentlichkeit gibt es allerdings noch nicht.

Eine klassische Desktopanwendung kann man mit .NET Core 5.0 zunächst nicht erzeugen. Alle Klassen aus Windows Forms und WPF fehlen zunächst in .NET Core. Das WPF-Team hat schon verkündet, dass man an der Modularisierung von WPF arbeitet. Eine entsprechende Ankündigung für Windows Forms ist jedoch nicht zu erwarten. Microsoft hat zugesagt, den .NET 4.x-Entwicklungszweig vorerst weiterhin zu pflegen; .NET 4.6 wird also nicht die letzte Version sein. Mittel- bis langfristig gehört die Zukunft aber natürlich .NET 5.x und seinen Nachfolgern.

Zu erwähnen ist in diesem Zusammenhang auch, dass Microsoft im November 2014 eine „Roadmap for WPF“ veröffentlicht hat. Zuvor hatte es Befürchtungen in der Benutzergemeinde gegeben, dass Microsoft WPF hinter Windows Forms auf das Abstellgleis schiebt. Tatsächlich gibt es in .NET Framework 4.6 kleinere Verbesserungen für WPF sowie das Bekenntnis aus Redmond, auch weiterhin an Funktionalität und Performanz von WPF zu arbeiten.

.NET Execution Environment

Wiederum in Abbildung 1 sieht man unterhalb von ASP.NET 5.0 einen weiteren neuen Begriff: „DNX“ steht für „.NET Execution Environment“. Man kann das DNX als eine Abstraktionsschicht sehen, die dafür sorgt, dass eine Anwendung sowohl auf unterschiedlichen Varianten von .NET als auch auf unterschiedlichen Plattformen laufen kann. DNX umfasst dabei ein Software Development Kit (SDK), Laufzeitumgebungen und Host-Prozesse für .NET-Anwendungen.

Im ersten Schritt gibt es DNX-Laufzeitumgebungen für .NET 4.6, Mono ab 3.4.x und .NET Core 5.0. Darüber hinaus können in späteren Zeiten weitere Versionen erstellt werden. Damit ist es heute möglich, dass ASP.NET-5.0-Anwendungen sowohl auf dem vollständigen .NET Framework 4.6 als auch auf dem modularen .NET-Core-5.0-Framework laufen. Sofern man im Programmcode keine Klassen bzw. Klassenmitglieder verwendet, die es auf der einen oder anderen .NET-Variante nicht gibt, ist der Wechsel zwischen den jeweiligen .NET-Varianten mit einem einzigen Kompilat möglich. Eine Fallunterscheidung im Programmcode ist durch Compiler-Switches möglich.

Zu DNX gehören auch Kommandozeilenwerkzeuge zur Verwaltung von Ausführungsumgebungen und zur Kompilierung bzw. Ausführung von Anwendungen. Der erste Schritt für die Entwicklung oder den Betrieb einer Anwendung auf Basis von DNX ist die Installation des DNX Version Manager (DNVM). Unter diesem Link ist die Vorgehensweise zur Installation des DNVM beschrieben. Sie erfolgt unter Windows durch das Herunterladen und Ausführen eines PowerShell-Skripts:

powershell -NoProfile -ExecutionPolicy unrestricted -Command "&{$Branch='dev';iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.ps1'))}"

Unter Linux kommt an dieser Stelle ein Bash-Shell-Skript zum Einsatz:

curl -sSL https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.sh | DNX_BRANCH=dev sh && source ~/.dnx/dnvm/dnvm.sh

Was die Skripte herunterladen, sind dann allerdings wieder nur Skripte mit dem oder den Namen dnvm.ps1 bzw. dnvm.sh. Unter Windows gibt es zusätzlich eine dnvm.bat-Datei, die das PowerShell-Skript dnvm.ps1 aufruft. Dieses Skript bietet dann mehrere Optionen (Abb. 4). Mithilfe von DNVM install kann man nun Ausführungsumgebungen aus dem Internet beziehen. Abbildung 5 zeigt, wie man die aktuelle Version von .NET Core 5.0 (zum Zeitpunkt der Erstellung dieses Beitrags Beta 4) herunterlädt. Die Größe liegt bei rund 14,3 MB. Entpackt auf der Festplatte sind es dann 35,8 MB in 239 Dateien, die man im Verzeichnis C:\Users\(name)\.dnx\runtimes findet. DNMV list liefert eine Liste der tatsächlich installierten DNX-Ausführungsumgebungen.

Zu der DNX-Ausführungsumgebung gehört dann wiederum ein Kommandozeilenwerkzeug DNU.cmd. Dieses „.NET Utility“ bietet Funktionen zum Auflisten der Abhängigkeiten eines Projekts zu NuGet-Paketen, zum Herunterladen von NuGet-Paketen, Kompilieren von Quellcode sowie zum Erstellen eines Veröffentlichungspakets. DNU.cmd ruft Funktionen in der Assembly Microsoft.Framework.PackageManager.dll auf und nutzt dazu ein weiteres Kommandozeilenwerkzeug DNX.exe. Und DNX.exe ist schließlich auch das Werkzeug, mit dem man eigenen kompilierten Programmcode starten kann. Wenn mehrere DNX-Ausführungsumgebungen installiert wurden, kann man mit DNVM use für den aktuellen Prozess die Ausführungsumgebung wählen, z. B. DNVM use 1.0.0-Beta4 –r CoreCLR –arch X64.

DNX-basierte Anwendungen werden nicht über XML-Dateien (app.config/web.config) konfiguriert, sondern durch JSON-Dateien mit dem Namen project.json. Wie Abbildung 1 zeigt, gibt es im Rahmen von ASP.NET 5 auch Konsolenanwendungen. Es handelt sich dabei jedoch um keine eigenständigen Executables, sondern DLL-Assemblies, die mit dnx.exe gestartet werden. Ansonsten arbeiten diese Konsolenanwendungen so wie „normale“ .NET-Konsolenanwendungen gemeinhin auch, also mit Main() als Einsprungpunkt. Sie sind hierbei dann allerdings plattformunabhängig.

Begrifflich kann es in der neuen Welt schwierig werden, sich eindeutig auf eine der .NET-Varianten zu beziehen. Dies merkt man auch an den Bezeichnungen, die Microsoft zukünftig in Portable Class Libraries verwenden wird. net steht da dann für das vollständige .NET 4.x und netcore für Windows 10 Universal Apps sowie dnx bzw dnxcore für ASP.NET auf .NET 4.x bzw. 5.x.

Abb. 1: .NET 2015 umfasst das .NET Framework 4.6 (gelb) und .NET Core 5.0 (rot)

Abb. 1: .NET 2015 umfasst das .NET Framework 4.6 (gelb) und .NET Core 5.0 (rot)

Abb. 2: Modularisierung der .NET-Klassen in .NET Core. Die Modularisierung von WPF ist in Arbeit, aber noch nicht veröffentlicht

Abb. 2: Modularisierung der .NET-Klassen in .NET Core. Die Modularisierung von WPF ist in Arbeit, aber noch nicht veröffentlicht

Abb. 3: Diese Liste zeigt, wie stark

Abb. 3: Diese Liste zeigt, wie stark Microsoft das .NET Framework modularisiert

Abb. 4: .NET Version Manager

Abb. 4: .NET Version Manager

Abb. 5: Installieren der aktuellen Version von .NET Core Open Source

Abb. 5: Installieren der aktuellen Version von .NET Core Open Source

Das bereits erwähnte Rotor-Projekt aus dem Jahr 2002 war nicht Open Source, sondern Shared Source, d. h., dass man hiermit lediglich experimentieren, aber kein Produkt erschaffen durfte. Das Mono-Entwicklungsteam bei Xamarin (bzw. den Vorgängerfirmen Ximian und Novell) konnte diesen Programmcode also nicht nutzen. Das galt auch für den zusätzlichen Quellcode, den Microsoft seit dem 16. Januar 2008 unter dem Titel „.NET Reference Source Project“ veröffentlichte.

ASP.NET MVC und ASP.NET Web API sind schon lange Open-Source-Projekte, und so verwunderte es auch nicht, dass Microsoft im Mai 2014 eine Open-Source-Entwicklung auch für den Nachfolger ASP.NET MVC 6 ankündigte. Ein größerer Paukenschlag war dann schon im November 2014 die Open-Source-Erklärung mit der MIT-Lizenz für das gesamte .NET Framework. Allerdings differenziert Microsoft hier zwischen .NET Framework 4.x und .NET Core 5.x. Softwareentwickler dürfen sich bei .NET Framework 4.x bedienen und den Quellcode für eigene Produkte nutzen. Dies umfasste im ersten Schritt einen großen Teil, aber noch nicht alles aus dem „.NET Reference Source Project“. Den unter Open-Source-Lizenz stehenden Teil findet man unter dieser Verlinkung. Insbesondere fehlt hier noch WPF. ASP.NET, WCF und WF sind aber vorhanden.

Von diesem GitHub Repository kann jedermann Gebrauch machen. Das am 1.5.2015 erschienene Mono 4.0 hat davon schon erheblich profitiert, indem man Teile von Mono, die fehlerhaft oder unvollständig waren, gegen den Microsoft-Code ausgetauscht hat. Für die Weiterentwicklung von .NET 4.x will Microsoft aber keine externen Entwickler zulassen, da das monolithische .NET 4.x sich dafür aus Sicht der Redmonder nicht eignet. Microsoft nutzt den Quellcode von .NET 4.x allerdings oftmals als Basis für .NET 5.x; schließlich will man das Rad noch runder machen, nicht aber ganz neu erfinden.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Bei .NET 5.x ist die Open-Source-Situation eine andere. Microsoft entwickelt hier auf Github.com vor den Augen der Öffentlichkeit und nimmt auch Beiträge von externen Entwicklern in Form von Pull-Requests an. Microsoft hat bereits zahlreiche Vorschläge angenommen. Auf GitHub kann jeder die einzelnen Work Items sehen; registrierte Benutzer können sie dort kommentieren oder neue Work Items einstellen.

Auf GitHub findet man den kompletten Quellcode der CoreCLR, aber noch nicht den aller .NET-Bibliotheken. Zum Zeitpunkt der Erstellung dieses Beitrags sind 44 Prozent der Core-Bibliotheken auf GitHub verfügbar. Welche das im Einzelnen sind, kann man der Liste entnehmen, wobei jedoch auch diese Liste nicht ganz aktuell ist, denn dort stehen WCF-Client-Bibliotheken (System.ServiceModel) noch auf „Coming“, während sie schon seit 20.5.2015 auf GitHub bereitstehen. Dass Microsoft nicht den kompletten Quellcode mit einem Schlag veröffentlicht, ist auch deshalb nachvollziehbar, da Microsofts Entwickler sicherlich noch einige Arbeiten (Refactoring, Codekommentare) erledigen möchten, bevor man den seit mehr als 15 Jahren entwickelten Programmcode zur Schau stellt.

Stufen der Beteiligung

Microsoft wird .NET Core wesentlich agiler weiterentwickeln als das bisherige .NET Framework. Aber nicht alle Unternehmen werden schnelle Aktualisierungen einzelner Komponenten mitmachen wollen oder können (aufgrund von notwendigen Zertifizierungen der Software, z. B. im medizinischen Bereich). Es gibt daher vier Möglichkeiten, wie man als .NET-Entwickler künftig .NET Core und seine Bibliotheken beziehen kann:

  1. Ganz nah am Puls der Zeit ist man, wenn man sich den jeweils ganz aktuellen Quellcode bei GitHub besorgt und selbst übersetzt. Dies werden die wenigsten .NET-Nutzer tun, da der Programmcode nicht umfangreich getestet ist. Aber im Einzelfall kann man so natürlich sofort von neuen Features und Bugfixes profitieren.
  2. Auf myget.org findet man jeweils die aktuellen Builds von Microsoft.
  3. Auf nuget.org findet man besser getestete Meilensteine, derzeit allerdings noch Betaversionen, da es noch keine RTM-Version von .NET Core gibt.
  4. Zukünftig will Microsoft auch offizielle .NET-Core-Distributionen in Form von Metapaketen auf NuGet veröffentlichen, die dann einen Satz von NuGet-Paketen umfassen, die Microsoft im Verbund gemeinsam getestet hat.

Microsoft erlaubt auch, einzelne Assemblies von .NET durch eigene Implementierungen auszutauschen und Fehler so selbst zu beheben. Bisher verhindern das die digitalen Signaturen. In DNX-Projekten wird nun aber ein lokales Quellcodeprojekt mit dem gleichen Namen wie ein NuGet-Paket gegenüber dem kompilierten Paket bevorzugt [Prinzip „Source over Binaries“], sodass der Austausch möglich ist.

Sprachen und Basisklassen

Sowohl .NET Framework 4.6 als auch .NET Core 5.0 bieten die neuimplementierten Sprachcompiler für C# 6 und Visual Basic 14. Diese beinhalten nicht nur neue Sprachfeatures (man beachte hierzu den Spickzettel in diesem Heft), sondern sind nun in Managed Code und ebenfalls modular implementiert, sodass sich Softwareentwickler in die verschiedenen Verarbeitungsschritte (Parser, Metadata Import, Binder, IL Emitter) einhängen können. Das vereinfacht die Entwicklung von IntelliSense-Funktionen, Refactorings, Codeanalyse, Codegenerierung etc., für die man bisher das komplexere Visual Studio SDK nutzen musste.

Ebenso liefert Microsoft in .NET Framework 4.6 und .NET Core 5.0 auch einen neuen, schnelleren Just-in-Time-Compiler für 64-Bit-basierte .NET-Anwendungen, den es seit Oktober 2013 als Preview unter dem Codename „Ryujit“ gibt. 32-Bit-Anwendungen profitieren davon aber zunächst nicht. Eine Implementierung für 32 Bit ist laut Microsoft aber in Arbeit.

Für beide .NET-2015-Frameworks gibt es ebenfalls einige neue Funktionen in den Basisklassen. Mit System.GC.TryStartNoGCRegion() und EndNoGCRegion() kann der Entwickler eine Coderegion definieren, in der die Garbage Collection nicht arbeiten soll. Dabei gibt der Entwickler bei TryStartNoGCRegion() eine Anzahl von Bytes an, die sowohl auf dem Small Object Heap als auch dem Large Object Heap zur Verfügung stehen müssen. Wenn diese Speichermenge zu Beginn nicht bereitsteht, findet eine volle, blockierende Garbage Collection vor Eintritt in diese Coderegion statt.

Beim Task-based Asynchronous Pattern (TAP) verwenden neue Tasks nicht mehr wie bisher die Kultureinstellungen der Windows-Systemeinstellungen, sondern die Kultur des Aufrufers.

Da es in .NET Core keine Application Domains mehr gibt, gibt es hier auch die Klasse System.AppDomain nicht mehr. Als Ersatz für System.AppDomain.CurrentDomain.BaseDirectory hat Microsoft System.AppContext.BaseDirectory eingeführt und die Klasse System.AppContext nun aber auch in .NET 4.6 verfügbar gemacht. Außerdem kann man in dieser Klasse globale, Assembly- und threadübergreifende Einstellungen mit SetSwitch() und TryGetSwitch() ablegen, die jedoch stets nur vom Typ bool sein dürfen.

Fazit

.NET ist im Umbruch, und das ist auch gut so. .NET-Entwickler können nun mit Segen und offizieller Unterstützung von Microsoft für alle Betriebssysteme entwickeln. Sicherlich fehlt noch ein plattformübergreifendes Desktop-UI-Framework. Aber es ist verständlich, dass die Modularisierung von .NET Zeit kostet, selbst wenn aktuell mehr Entwickler im .NET-Team arbeiten als jemals zuvor. Schließlich entstehen parallel ja auch noch neue Funktionen. Es wird mithin also noch einige Zeit dauern, bis .NET Core eine gewisse Reife für den Praxiseinsatz erreicht hat.

Produktstatus
.NET Framework 4.6 und Visual Studio 2015 sind am 20.07.2015 erschienen, CoreCLR mit .NET Native für Windows-10-Apps wurde zusammen mit Windows 10 am 29.07.2015 veröffentlicht. Mehr Zeit lassen kann sich Microsoft mit den DNX-basierten Anwendungen (ASP.NET und Konsolenanwendungen), diese sind Ende Juli 2015 auf dem Status Beta 5.
Aufmacherbild: Colored cubes in empty space von Shutterstock / Urheberrecht: VAlex
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -