Eingeführt von .NET 5

Am 6. Mai wurde bekannt gegeben, dass die nächste Version nach .NET Core 3.0 .NET 5 sein wird. Dies wäre die nächste große Version in der .NET-Familie.

In Zukunft wird es nur noch ein .NET geben, das Sie für die Entwicklung unter Windows, Linux, MacOS, iOS, Android, TVOS, WatchOS, WebAssembly und anderen Plattformen verwenden können.

Wir werden die neuen .NET-APIs, Laufzeitfunktionen und Sprachfunktionen als Teil von .NET 5 vorstellen.



Seit dem Start des .NET Core-Projekts haben wir der Plattform etwa 50.000 API .NET Framework hinzugefügt. So weit wie möglich kam .NET Core 3.0 dem .NET Framework 4.8 nahe, dank dessen Windows Forms, WPF und Entity Framework 6 verfügbar wurden. .NET 5 übernahm den Staffelstab, basierte auf .NET Core und war das Beste aus dem Mono- Projekt Es stellte sich heraus, dass es sich um eine einzige Plattform handelt, die für Ihren gesamten modernen .NET-Code verwendet werden kann.

Wir beabsichtigen, .NET 5 im November 2020 zu veröffentlichen. Die erste Vorschau-Version wird in der ersten Hälfte des Jahres 2020 verfügbar sein. Die Plattform wird zusammen mit zukünftigen Updates für Visual Studio 2019, Visual Studio für Mac und Visual Studio Code verfügbar sein.

.NET 5 = .NET Core vNext

.NET 5 ist der nächste Schritt in .NET Core. Das Projekt zielt darauf ab, .NET in mehreren wichtigen Aspekten zu verbessern:

• Erstellen Sie eine einzelne Laufzeit und ein Framework, die überall verwendet werden können, mit demselben Laufzeitverhalten und derselben Entwicklungserfahrung.
• Erweitern Sie .NET mit den besten Funktionen von .NET Core, .NET Framework, Xamarin und Mono.
• Erstellen Sie ein Produkt aus einer einzigen Codebasis, auf der Entwickler (von Microsoft und der Community) zusammenarbeiten und es erweitern können, um alle möglichen Szenarien zu verbessern.

Dieses neue Projekt und diese neue Richtung werden die Situation mit .NET vollständig verändern. Dank .NET 5 sehen Ihre Code- und Projektdateien unabhängig von der Art der Anwendung, die Sie erstellen, konsistent aus. Von jeder Anwendung aus haben Sie Zugriff auf dieselbe Laufzeit, dieselbe API und dieselben Sprachfunktionen, einschließlich neuer Leistungsverbesserungen , die fast täglich in corefx implementiert werden.

Alles, was Sie an .NET Core mögen, wurde beibehalten:

• Open Source und Community konzentrieren sich auf GitHub.
• Plattformübergreifende Implementierung.
• Unterstützung für die Verwendung spezifischer plattformspezifischer Funktionen wie Windows Forms und WPF für Windows sowie native Bindungen für jede native Plattform von Xamarin.
• Hohe Leistung.
• Side-by-Side-Installation.
• Kleine Projektdatei (SDK-Stil).
• Leistungsstarke Befehlszeilenschnittstelle (CLI).
• Integration mit Visual Studio, Visual Studio für Mac und Visual Studio Code.

Innovationen:

• Sie haben mehr Laufzeitfunktionen (mehr dazu weiter unten).
• Die Möglichkeit, Java-Code aus .NET 5 aufzurufen, ist auf allen Plattformen verfügbar.
• Der Aufruf von Objective-C- und Swift-Code aus .NET 5 wird auf mehreren Betriebssystemen unterstützt.
• CoreFX wird erweitert, um die statische .NET-Kompilierung (AOT) zu unterstützen, den Platzbedarf zu verringern und mehr Betriebssysteme zu unterstützen.

.NET Core 3.0 wird im September dieses Jahres und .NET 5 im November 2020 verfügbar sein. Danach werden wir jedes Jahr im November Hauptversionen von .NET veröffentlichen:



Wir überspringen die vierte Version, da Benutzer möglicherweise mit dem .NET Framework verwechselt werden, das seit langem in Version 4.x veröffentlicht wurde. Darüber hinaus wollten wir klarstellen, dass .NET 5 die Zukunft der .NET-Plattform ist.

Wir haben uns auch entschlossen, diese Gelegenheit zu nutzen und die Reihenfolge der Namen zu vereinfachen. Wir glauben, dass wir, wenn sich nur ein .NET entwickelt, den erklärenden Begriff „Kern“ nicht benötigen. Der Kurzname ist einfacher, dh die Funktionen und das Verhalten von .NET 5 sind vereinheitlicht. Wenn Sie möchten, können Sie den Namen NET Core weiterhin verwenden.

Laufzeitumgebungen

Mono ist die ursprüngliche plattformübergreifende Implementierung von .NET. Es begann als Open-Source-Alternative zu .NET Framework und wurde später mit der wachsenden Beliebtheit von iOS- und Android-Geräten auf das mobile Segment ausgerichtet. Mono ist eine Laufzeitumgebung, die als Teil von Xamarin verwendet wird.

CoreCLR ist eine Laufzeitumgebung, die als Teil von .NET Core verwendet wird. Ursprünglich auf die Unterstützung von Cloud-Anwendungen ausgerichtet, einschließlich der größten Dienste bei Microsoft, wird es heute auch für Windows-Desktopanwendungen, IoT und maschinelles Lernen verwendet.

Die .NET Core- und Mono-Laufzeiten haben viele Gemeinsamkeiten (beide sind jedoch .NET-Laufzeiten), aber jede hat ihre eigenen Funktionen. Daher ist es sinnvoll, Ihnen die Möglichkeit zu geben, die von Ihnen benötigte Nutzungserfahrung zu wählen. Wir arbeiten derzeit daran, CoreCLR- und Mono-Plug-In-Ersetzungen für einander vorzunehmen. Der Vorgang ist so einfach wie das Umschalten der Baugruppe, um zwischen verschiedenen Laufzeitoptionen zu wählen.

In den folgenden Kapiteln werde ich unsere wichtigsten Pläne für .NET 5 beschreiben. Sie helfen Ihnen zu verstehen, wie wir zwei Laufzeiten gleichzeitig und zur selben Zeit getrennt entwickeln werden.

Hohe Produktivität und Produktivität

.NET war von Anfang an auf einen JIT-Compiler angewiesen, um Intermediate Language-Code in optimierten Maschinencode umzuwandeln. Wir haben mit JIT die branchenweit beste Laufzeitumgebung mit sehr hoher Leistung geschaffen, während Entwickler schnell und einfach Code schreiben können.

JIT-Compiler eignen sich gut für lang laufende Clouds und Client-Skripte. Sie können Code generieren, der die Merkmale der Hardwarekonfiguration berücksichtigt, einschließlich spezifischer Prozessoranweisungen. JIT kann auch zur Laufzeit wieder Methoden generieren. Mit dieser Technik können Sie mit hoher Geschwindigkeit kompilieren und gleichzeitig eine fein abgestimmte Version des Codes erstellen, wenn einige Methoden häufig verwendet werden.

Unsere Bemühungen, die Leistung von ASP.NET Core zu beschleunigen, die sich in den Ergebnissen der TechEmpower- Benchmarks widerspiegeln , sind ein gutes Beispiel für die Funktionen von JIT und unser Beitrag zu CoreCLR. Wir haben versucht, .NET Core für die Verwendung von Containern vorzubereiten. Dies zeigt die Fähigkeit der Laufzeitumgebung, sich dynamisch an begrenzte Umgebungen anzupassen.

Entwicklertools sind ein weiterer Bereich, in dem sich JIT bewährt hat, z. B. Dotnet Watch oder der Modus „Bearbeiten und Fortfahren“. Tools erfordern häufig das Kompilieren und Herunterladen von Code im selben Prozess viele Male ohne Neustart, und Sie müssen dies sehr schnell tun.

Entwickler, die .NET Core oder .NET Framework verwenden, verlassen sich hauptsächlich auf JIT. So sollte es ihnen vertraut erscheinen.

Der Standardansatz für die meisten .NET 5-Workloads besteht darin, die CoreCLR-Laufzeit mit JIT zu verwenden. Zwei wichtige Ausnahmen sind iOS und Client Blazor (WebAssembly). Sie erfordern eine native vorläufige Kompilierung (vorab).

Schneller Start, geringer Platzbedarf und geringerer Speicherbedarf

Im Rahmen des Mono-Projekts richteten sich die meisten Bemühungen auf das mobile Segment und die Spielekonsolen. Die Hauptgelegenheit und das Ergebnis dieses Projekts ist der AOT-Compiler für .NET, der auf der Grundlage des LLVM- Compilers entwickelt wurde. Mit dem Mono AOT-Compiler können Sie .NET-Code in einen einzigen nativen ausführbaren Code kompilieren, der genau wie C ++ - Code auf jedem Computer ausgeführt werden kann. Vorkompilierte (AOT) Anwendungen können mit begrenzten Ressourcen (kleinen Plätzen) effizient ausgeführt werden und bei Bedarf die Leistung für ihren Start opfern.

Das Blazor- Projekt verwendet bereits Mono AOT und ist eines der ersten, das auf .NET 5 umgestellt hat . Wir verwenden es als eine Möglichkeit, unsere Pläne zu beweisen.

Es gibt zwei Arten von AOT-Lösungen:

• Vollständige AOT-Kompilierung erforderlich.
• Lösungen, deren Code größtenteils AOT-kompiliert ist, die es Ihnen jedoch weiterhin ermöglichen, eine JIT oder einen Interpreter für solche Codemuster zu verwenden, die nicht mit AOT befreundet sind (z. B. Generika).

Mono AOT unterstützt beide Typen. AOT des ersten Typs wird für iOS und einige Spielekonsolen benötigt. Dies ist hauptsächlich auf Sicherheitsanforderungen zurückzuführen. Lösungen des zweiten Typs sind vorzuziehen, da sie alle Vorteile von AOT ohne dessen Nachteile aufweisen.

Der .NET Native ist der AOT-Compiler, den wir für Windows UWP-Anwendungen verwenden. Es gehört zur ersten Art von AOT-Lösungen. In dieser speziellen Implementierung haben wir die .NET-API und die Ihnen zur Verfügung stehenden Optionen eingeschränkt. Dies hat uns zu dem Verständnis verholfen, dass AOT-Lösungen die gesamte Bandbreite der .NET-APIs und -Muster abdecken sollten.

Die AOT-Kompilierung bleibt für iOS, WebAssembly und einige Spielekonsolen erforderlich. Wir werden es optional für Anwendungen machen, die in Appliances eingebettet sind (Appliance-ähnlich), die einen schnellen Start und / oder einen geringen CPU-Verbrauch erfordern.

Grundlagen und damit verbundene Anforderungen

Für uns ist es wichtig, uns als Plattform mit Steuerelementen für Start, Leistung, Speicherverbrauch, Zuverlässigkeit und Diagnose weiterzuentwickeln. Gleichzeitig ist es ratsam, unsere Bemühungen zu konzentrieren. Wir werden weiter daran arbeiten, die Leistung und Zuverlässigkeit von CoreCLR zu verbessern sowie den Start und die Reduzierung der Dateigröße des Mono AOT-Compilers zu verbessern. Es scheint uns eine gute Kombination zu sein. Leistung und Zuverlässigkeit gehen Hand in Hand, ebenso wie die Startgeschwindigkeit bei reduzierten Dateigrößen.

Es ist ratsam, unterschiedliche Ressourcen in die Verbesserung einiger Merkmale zu investieren, nicht jedoch in die Verbesserung anderer.

Die Diagnosefunktionen sollten in .NET 5 gleich sein. Dies gilt sowohl für die Funktionalität als auch für die Leistung. Es ist auch wichtig, dieselben Prozessoren und Betriebssysteme zu unterstützen (mit Ausnahme von iOS und WebAssembly).

Wir werden .NET 5 weiterhin für alle Arten von Workloads und Skripten optimieren, für die dies sinnvoll ist. Der größte Schwerpunkt wird auf Optimierungen gelegt, insbesondere in Fällen, in denen unterschiedliche Lasten ähnliche Anforderungen stellen.

Alle .NET 5-Anwendungen verwenden das CoreFX- Framework. Wir werden sicherstellen, dass CoreFX dort gut funktioniert, wo es heute nicht verwendet wird, hauptsächlich für Blazor-Aufgaben des Xamarin-Clients.

Alle .NET 5-Anwendungen können mithilfe der .NET-CLI erstellt werden , sodass Sie in allen Projekten über ein einziges Toolkit verfügen, das auf der Befehlszeile basiert.

C # wird mit .NET 5 weiterentwickelt. Entwickler, die .NET 5-Anwendungen schreiben, haben Zugriff auf die neueste Version von C # und seine Eigenschaften.

Projektgeburt

Als technisches Team haben wir uns im Dezember 2018 in Boston versammelt, um dieses Projekt zu starten. Führende Architekten des .NET-Teams (Mono / Xamarin und .NET Core) und von Unity sprachen über verschiedene technische Funktionen und die Entwicklungsrichtung der Architektur.

Jetzt bewegen wir das Projekt als Team. Seit Dezember haben wir in mehreren Projekten große Fortschritte erzielt:

• Wir haben die Mindeststufe festgelegt, die das Zusammenspiel von Laufzeit und verwalteter Codeschicht bestimmt, um> 99% CoreFX zu einem gemeinsamen Code zu machen.
• MonoVM kann jetzt CoreFX und seine Klassenbibliotheken verwenden.
• Wir haben alle CoreFX-Tests auf MonoVM mit seiner Implementierung ausgeführt.
• Startete ASP.NET Core 3.0-Anwendungen auf MonoVM.
• Startete MonoDevelop und Visual Studio für Mac auf CoreCLR.

Das Streben nach einer einzigen .NET-Implementierung wirft wichtige Fragen auf. Was wird der endgültige Rahmen sein? Bleiben die NuGet-Paketkompatibilitätsregeln bestehen? Welche Last wird das .NET 5 SDK sofort unterstützen? Wie schreibe ich Code für eine bestimmte Architektur? Benötigen wir .NET Standard? Jetzt arbeiten wir an all dem und können Ihnen in Kürze die Projektdokumentation zur Verfügung stellen, damit Sie sie lesen und Feedback geben können.

Fazit

Das .NET 5-Projekt ist eine wichtige und inspirierende neue Richtung für .NET. Sie werden sehen, dass .NET einfacher wird, aber gleichzeitig wird es weiter verbreitet und es wird mehr Möglichkeiten geben. Alle neuen Entwicklungsfunktionen werden Teil von .NET 5, einschließlich neuer Versionen von C #.

Wir haben eine glänzende Zukunft vor uns, in der Sie dieselben .NET-APIs und -Sprachen für eine Vielzahl von Anwendungen, Betriebssystemen und Prozessorarchitekturen verwenden können. Sie können die Build-Konfiguration einfach ändern, indem Sie Anwendungen nach Ihren Wünschen zusammenstellen - in Visual Studio, Visual Studio für Mac, Visual Studio-Code, Azure DevOps oder über die Befehlszeile.