Heute geben wir bekannt, dass die nächste Version nach .NET Core 3.0 .NET 5 sein wird. Dies wird die nächste große Veröffentlichung der .NET-Reihe sein.
In Zukunft wird es nur noch ein .NET geben, mit dem Sie unter anderem Windows, Linux, macOS, iOS, Android, tvOS, watchOS und WebAssembly entwickeln können.
Wir führen neue .NET-APIs, Laufzeitfunktionen und Sprachfunktionen in .NET 5 ein.
Beginnend mit dem .NET Core-Projekt haben wir etwa fünfzigtausend .NET Framework APIs zur Plattform hinzugefügt. .NET Core 3.0 schließt die meisten der verbleibenden Funktionslücken von .NET Framework 4.8 und unterstützt Windows Forms, WPF und Entity Framework 6. .NET 5 baut auf dieser Arbeit auf und nutzt die besten Funktionen von .NET Core und Mono, um eine Plattform zu schaffen. Man kann es für den gesamten modernen .NET-Code verwenden.
Wir beabsichtigen, .NET 5 im November 2020 zu veröffentlichen und die erste Vorschau in der ersten Hälfte des Jahres 2020 zu starten. Es wird in zukünftigen Updates für Visual Studio 2019, Visual Studio für Mac und Visual Studio Code unterstützt.
.NET 5 = .NET Core vNext
.NET 5 ist der nächste Schritt in .NET Core. Das Projekt zielt darauf ab, die . NETTO:
- Baue eine .NET-Laufzeit und ein Framework, das überall verwendet werden kann, mit einheitlichem Laufzeitverhalten und Entwicklererfahrung.
- Durch die volle Nutzung von .NET Core gilt . NET Framework, Xamarin und Mono, um die Fähigkeiten von .NET zu erweitern.
- Indem das Produkt aus einer einzigen Codebasis basiert, können Entwickler (Microsoft und die Community) zusammenarbeiten und gemeinsam alle Szenarien verbessern.
Dieses neue Projekt und diese neue Richtung sind ein wichtiger Wendepunkt für .NET. Mit .NET 5 sind dein Code und deine Projektdateien unabhängig von der Art der Anwendung gleich. Jede App hat Zugriff auf dieselben Laufzeit-, API- und Sprachfunktionen. Beinhaltet außerdem Performance-Verbesserungen für CoreFX, die fast täglich vorgenommen werden.
Alles, was Sie an .NET Core lieben, wird weiterhin bestehen:
- Open Source und gemeinschaftsorientiert auf GitHub.
- Plattformübergreifende Implementierung.
- Unterstützung für die Nutzung plattformspezifischer Funktionen wie Windows-Formulare und WPF unter Windows sowie native Bindings für jede native Plattform von Xamarin.
- Hohe Leistung.
- Installiert sie nebeneinander.
- Kleine Projektdateien (SDK-Stil).
- Kompatibel mit Kommandozeilenschnittstellen (CLIs).
- Visual Studio, Visual Studio für Mac und Visual Studio Code-Integration.
Es gibt auch einige neue Dinge:
- Du hast mehr Optionen für dein Laufzeit-Erlebnis (mehr dazu unten).
- Java-Interoperabilität wird auf allen Plattformen verfügbar sein.
- Mehrere Betriebssysteme werden die Interoperabilität von Objective-C und Swift unterstützen.
- CoreFX wird erweitert, um Voraus-of-Time (AOT) für .NET, einen kleineren Footprint und mehr Betriebssysteme zu unterstützen.
Wir werden .NET Core 3.0 im September dieses Jahres veröffentlichen, .NET 5 im November 2020, und danach beabsichtigen wir, eine Hauptversion der . NETTO:
Wir haben Version 4 übersprungen, weil es Nutzer verwirren würde, die mit dem .NET Framework vertraut sind, das mit der 4.x-Serie schon lange existiert. Außerdem möchten wir klar kommunizieren, dass .NET 5 die Zukunft der .NET-Plattform ist. Es als .NET 5 zu bezeichnen, macht es zur höchsten Version, die wir je veröffentlicht haben.
Wir nutzen diese Gelegenheit auch, um die Benennung zu vereinfachen. Wir denken, wenn nur ein .NET das Beste ist, brauchen wir keinen klärenden Begriff wie "Core". Der kürzere Name ist eine Vereinfachung und vermittelt auch die Botschaft, dass .NET 5 einheitliche Funktionalität und Verhalten besitzt. Natürlich können Sie weiterhin den Namen ".NET Core" verwenden, wenn Sie möchten.
Laufzeit-Erfahrung
Mono ist die ursprüngliche plattformübergreifende Implementierung von .NET. Es begann als Open-Source-Alternative zum .NET Framework und entwickelte sich mit der Beliebtheit von iPhone/iOS- und Android-Geräten zu mobilspezifisch. Mono ist eine Laufzeit, die als Teil von Xamarin verwendet wird.
CoreCLR ist eine Laufzeit, die als Teil von .NET Core verwendet wird. Es wird hauptsächlich zur Unterstützung von Cloud-Anwendungen verwendet, darunter Microsofts größten Dienst, und wird inzwischen auch in Windows-Desktop-, IoT- und Machine-Learning-Anwendungen eingesetzt.
Zusammenfassend teilen die .NET Core- und Mono-Laufzeiten viele Gemeinsamkeiten (schließlich sind sie beide .NE-Laufzeiten), aber sie verfügen auch über wertvolle einzigartige Merkmale. Es macht viel Sinn, es möglich zu machen, das gewünschte Laufzeit-Erlebnis auszuwählen. Wir machen CoreCLR und Mono austauschbar miteinander. Wir machen es so einfach, einen Switch zu bauen, um zwischen verschiedenen Laufzeitoptionen zu wählen.
Die folgenden Abschnitte beschreiben den Hauptfokus, den wir für .NET 5 verwenden wollen. Sie bieten eine klare Perspektive darauf, wie wir diese beiden Laufzeiten einzeln und gemeinsam weiterentwickeln wollen.
Hoher Durchsatz und hohe Produktivität
Von Anfang an setzte .NET auf Just-in-Time-Compiler (JITs), um Intermediate Language (IL)-Code in optimierten Maschinencode umzuwandeln. Seitdem haben wir eine branchenführende, JIT-basierte verwaltete Laufzeitumgebung aufgebaut, die einen sehr hohen Durchsatz bietet und zudem das Entwicklererlebnis verbessert, wodurch das Programmieren schnell und einfach wird.
JIT ist ideal für langfristige Cloud- und Client-Szenarien. Sie sind in der Lage, Code zu generieren, der für bestimmte Maschinen konfiguriert ist, einschließlich bestimmter CPU-Befehle. JIT kann auch Methoden zur Laufzeit regenerieren, eine Technik, die JIT schneller macht, während sie dennoch die Möglichkeit hat, hochoptimierte Codeversionen zu generieren, falls diese häufig verwendet wird.
Unsere Bemühungen, ASP.NET Core auf dem Techpower-Benchmark schneller laufen zu lassen, sind ein großartiges Beispiel für die Stärke von JIT und unsere Investition in CoreCLR. Unsere Bemühungen, .NET Core für Container zu verhärten, sind ebenfalls ein Beweis für die Fähigkeit der Laufzeit, sich dynamisch an eingeschränkte Umgebungen anzupassen.
Entwickler-Tools sind ein weiteres großartiges Beispiel dafür, wie JIT wirklich großartig ist, wie Dotnet-Watch-Tools oder Bearbeiten und Fortsetzen. Werkzeuge müssen oft Code mehrfach in einem einzigen Prozess kompilieren und laden, ohne neu zu starten, und das sehr schnell.
Entwickler, die .NET Core oder .NET Framework verwenden, verlassen sich hauptsächlich auf JIT. Daher sollte die Erfahrung vertraut sein.
Das Standard-Erlebnis für die meisten .NET 5-Szenarien verwendet die JIT-basierte CoreCLR-Laufzeit. Zwei bemerkenswerte Ausnahmen sind iOS und Client Blazor (Web-Assembly), da beide eine vorauszeitliche (AOT) native Kompilierung erfordern.
Schneller Start, kleiner Bedarf und geringer Speicherverbrauch
Der Großteil des Mono-Projekts konzentrierte sich auf Mobilgeräte und Konsolen. Ein zentrales Merkmal und Ergebnis des Projekts ist der .NET AOT-Compiler, der auf dem branchenführenden LLVM-Compiler-Projekt basiert. Der Mono AOT-Compiler ermöglicht es, .NET-Code in eine native Code-ausführbare Datei einzubauen, die auf einem Computer ausgeführt werden kann, genau wie C++-Code. AOT-kompilierte Anwendungen können effizient an kleineren Standorten laufen und bei Bedarf den Durchsatz für den Start austauschen.
Das Blazor-Projekt verwendet bereits Mono AOT. Dies wird eines der ersten Projekte sein, das auf .NET 5 umgestellt wird. Wir nutzen es als eine der Optionen, um diesen Plan zu beweisen.
Es gibt zwei Arten von AOT-Lösungen:
- Erfordert eine Lösung, die zu 100 % AOT-kompiliert ist.
- Der meiste Code ist eine von AOT kompilierte Lösung, aber JIT oder Interpreter können für Codemuster verwendet werden, die nicht AOT-freundlich sind (wie zum Beispiel Generik). Mono AOT unterstützt beide Fälle. Apple verlangt aus Sicherheitsgründen das erste AOT für iOS und einige Konsolen. Die zweite Methode ist eine bessere Option, da sie die Vorteile von AOT bietet und einige Nachteile vermeidet.
.NET Native ist unser AOT-Compiler für Windows UWP-Anwendungen und ist auch ein Beispiel für den oben genannten ersten AOT-Typ. In dieser speziellen Implementierung beschränken wir die .NET-API und die Funktionen, die du nutzen kannst. Aus dieser Erfahrung haben wir gelernt, dass AOT-Lösungen alle Aspekte von .NET-APIs und -Mustern abdecken müssen.
AOT-Kompilierung ist weiterhin auf iOS, Webassembler und einigen Konsolen erforderlich. Für Anwendungen, die schnelleren Start oder einen geringen Fußabdruck erfordern, machen wir die AOT-Kompilierung zu einer Option.
Die Entstehung des Projekts
Wir haben dieses Projekt im Dezember 2018 mit einem technischen Team in Boston begonnen. Designleiter aus dem .NET-Team (Mono/Xamarin und .NET Core) und Unity präsentierten eine Vielzahl technischer Fähigkeiten und architektonischer Richtungen.
Wir bringen dieses Projekt nun als Team mit einer Reihe von Ergebnissen voran. Seit Dezember haben wir bei mehreren Projekten große Fortschritte gemacht:
- Eine Mindestschicht ist definiert, die die Laufzeit-<-> verwaltete Codeschicht definiert, mit dem Ziel, >99 % des öffentlichen CoreFX-Codes zu erreichen.
- MonoVM kann jetzt CoreFX und seine Klassenbibliotheken verwenden.
- Führe alle CoreFX-Tests auf der MonoVM mit der CoreFX-Implementierung durch.
- Führe ASP.NET Core 3.0-Anwendungen mit MonoVM aus.
- Führe MonoDevelop auf CoreCLR aus und starte dann Visual Studio für Mac.
Migration zu einer einzigen . Die .NET-Implementierung wirft einige wichtige Fragen auf: Was wird das Zielrahmen sein? Sind die NuGet-Paket-Kompatibilitätsregeln gleich? Welche Workloads sollte das .NET 5 SDK unterstützen? Wie programmiere ich für eine bestimmte Architektur? Brauchen wir noch .NET Standard?
Wir arbeiten jetzt an diesen Themen und werden dir bald das Designdokument zur Verfügung stellen, damit du es lesen und Feedback geben kannst.
Epilog
Das .NET 5-Projekt ist eine wichtige und spannende neue Richtung für .NET. Du wirst sehen, dass .NET einfacher wird, aber auch eine größere Bandbreite an Funktionen und Nutzen bietet. Alle neuen Entwicklungen und Funktionen werden Teil von .NET 5 sein, einschließlich neuer C#-Versionen.
Wir sehen eine vielversprechende Zukunft, in der man dieselben .NET-APIs und -Sprachen nutzen kann, um eine breite Palette von Anwendungstypen, Betriebssystemen und Silizium-Architekturen anzusprechen. In Visual Studio, Visual Studio für Mac, Visual Studio Code, Azure DevOps oder der Kommandozeile ist es einfach, die Build-Konfiguration zu ändern, um verschiedene Anwendungen zu erstellen.
Originallink:Der Hyperlink-Login ist sichtbar.
|
Veröffentlicht am 07.05.2019 09:41:27
|
|
|
|
