Letzte Woche wurde .NET Core 3.0 (Vorschau 6) veröffentlicht . Es enthält Aktualisierungen der Assembly-Kompilierung, um den Start zu verbessern und die Optimierung der Anwendungsgröße mit Linker- und EventPipe-Verbesserungen zu verbessern. Wir haben auch neue Docker-Images für Alpine auf ARM64 veröffentlicht.
WPF- und Windows Forms-Updates
Das WPF-Team hat den Prozess der Veröffentlichung des größten Teils des WPF-Codes auf GitHub abgeschlossen . Tatsächlich haben sie gerade den Quellcode für fünfzehn Builds veröffentlicht . Für diejenigen, die mit WPF vertraut sind, sollten Baugruppennamen sehr vertraut sein.
In einigen Fällen befinden sich die Tests noch im Rückstand und müssen in oder vor 3.0 GA veröffentlicht werden. Das Vorhandensein dieses gesamten Codes sollte es der WPF-Community jedoch ermöglichen, sich uneingeschränkt an Änderungen an WPF zu beteiligen. Nachdem Sie einige Probleme mit GitHub gelesen haben, wird deutlich, dass die Community über einen eigenen Rückstand an neuen Produkten verfügt, die Sie implementieren möchten. Was denkst du über das dunkle Thema?
Alpine Docker Bilder
Docker-Images sind jetzt sowohl für .NET Core als auch für ASP.NET Core auf ARM64 verfügbar. Bisher waren sie nur für x64 verfügbar.
Die folgenden Bilder können in der Dockerfile oder mit docker pull , wie unten gezeigt:
docker pull mcr.microsoft.com/dotnet/core/runtime:3.0-alpine-arm64v8docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0-alpine-arm64v8
Event Pipe-Verbesserungen
Event Pipe unterstützt jetzt Multisessionalität.
Neue Leistungsindikatoren hinzugefügt:
- % Zeit in GC
- Gen 0 Heap Size
- Gen 1 Heap Size
- Gen 2 Heap Size
- LOH Heap Size
- Zuteilungsrate
- Anzahl der geladenen Baugruppen
- Anzahl der ThreadPool-Threads
- Überwachungssperrkonfliktrate
- ThreadPool Work Items Queue
- ThreadPool-Rate abgeschlossener Arbeitselemente
Profiler-Joins werden jetzt mit derselben Event Pipe-Infrastruktur implementiert.
Lesen Sie das Zählspiel von David Fowler, um eine Vorstellung davon zu bekommen, was Sie mit der Event-Pipe tun können, um Ihre eigene Leistungsforschung durchzuführen oder einfach den Status der Anwendung zu verfolgen.
Lesen Sie die Dotnet-Zähler , um das Dotnet-Zähler-Tool zu installieren.
Optimieren Sie Ihre .NET Core-Anwendungen mit ReadyToRun-Images
Sie können die Startzeit einer .NET Core-Anwendung verbessern, indem Sie Anwendungsbuilds im ReadyToRun (R2R) -Format kompilieren. R2R ist eine Form der führenden Zusammenstellung (AOT).
R2R-Binärdateien verbessern die Startleistung, indem sie den Arbeitsaufwand reduzieren, den JIT beim Laden der Anwendung leisten muss. Die Binärdateien enthalten Maschinencode, der dem von der JIT generierten ähnlich ist, wodurch die JIT eine Pause einlegt, wenn die Leistung am wichtigsten ist (beim Start). Die Binärdateien im R2R-Format sind größer, da sie sowohl IL-Code (Intermediate Language), der für einige Szenarien noch erforderlich ist, als auch eine Maschinenversion desselben Codes enthalten, um den Start zu verbessern.
R2R wird von .NET Core 3.0 unterstützt. Es kann nicht mit früheren Versionen von .NET Core verwendet werden.
Beispielleistungszahlen
Die folgenden Abbildungen zeigen die Leistung von Beispielen für WPF-Anwendungen . Die Anwendung wurde als eigenständige Anwendung veröffentlicht und verwendete nicht den Assembly-Linker (weiter unten in diesem Artikel beschrieben).
Nur-IL-Anwendung:
- Startzeit: 1,9 Sekunden
- Speichernutzung: 69,1 MB
- Anwendungsgröße: 150 MB
Mit ReadyToRun-Bildern:
- Startzeit: 1,3 Sekunden.
- Speichernutzung: 55,7 MB
- Anwendungsgröße: 156 MB
Lesen Sie mehr über ReadyToRun-Bilder
Sie können R2R sowohl für Bibliotheken als auch für Anwendungsbinärdateien kompilieren. Derzeit können Bibliotheken nur als Teil der Anwendung in R2R kompiliert werden und nicht als NuGet-Paket. Wir möchten mehr Feedback darüber, ob dieses Szenario wichtig ist.
Die Kompilierung von AOT-Assemblys ist seit langem als Konzept für .NET verfügbar und kehrt zu .NET Framework und NGEN zurück . Ein wesentlicher Nachteil von NGEN besteht darin, dass die Kompilierung auf Client-Computern mit dem NGEN-Tool durchgeführt werden muss. Es ist nicht möglich, NGEN-Images als Teil Ihres Anwendungsbuilds zu generieren.
Jetzt .NET Core. Es wird mit crossgen geliefert , das Maschinenbilder im neuen ReadyToRun- Format erzeugt. Der Name beschreibt seinen Kernwert, nämlich dass diese Maschinenabbilder als Teil Ihrer Baugruppe erstellt werden können und ohne zusätzliche Arbeit auf Client-Computern „betriebsbereit“ sind. Dies ist eine wesentliche Verbesserung sowie ein wichtiger Sieg im Kampf gegen den Klimawandel.
In Bezug auf die Kompatibilität ähneln ReadyToRun-Images IL-Assemblys mit einigen wesentlichen Unterschieden.
- IL-Assemblys enthalten nur IL-Code . Sie können in jeder Laufzeitumgebung arbeiten, die die angegebene Zielinfrastruktur für diese Assembly unterstützt. Beispielsweise kann der Build
netstandard2.0 .NET Framework 4.6+ und .NET Core 2.0+ unter allen unterstützten Betriebssystemen (Windows, MacOS, Linux) und Architekturen (Intel, ARM, 32-Bit, 64-Bit) ausgeführt werden. - R2R-Assemblys enthalten IL und nativen Code. Sie werden für eine bestimmte Mindestversion der .NET Core-Laufzeit und der Laufzeitumgebung (RID) kompiliert. Beispielsweise kann der
netstandard2.0 Build für .NET Core 3.0 und Linux x64 R2R-kompiliert werden. Es wird nur in dieser oder einer kompatiblen Konfiguration verwendet (z. B. .NET Core 3.1 oder .NET Core 5.0 unter Linux x64), da es nativen Code enthält, der nur in dieser Laufzeitumgebung verwendet werden kann.
Anleitung
Die ReadyToRun-Kompilierung kann nur veröffentlicht werden. Die Vorschau-Version wurde in .NET Core 3.0 (Vorschau 5) veröffentlicht.
Um die ReadyToRun-Kompilierung zu aktivieren, müssen Sie:
- Setzen Sie den Wert der
PublishReadyToRun Eigenschaft auf true . - Posten Sie mit dem genauen
RuntimeIdentifier .
Hinweis Wenn die Builds der Anwendung kompiliert werden, hängt der generierte native Code von der Plattform und der Architektur ab (daher müssen Sie beim Veröffentlichen einen gültigen RuntimeIdentifier angeben).
Hier ist ein Beispiel:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishReadyToRun>true</PublishReadyToRun> </PropertyGroup> </Project>
Und Veröffentlichen mit dem folgenden Befehl:
dotnet publish -r win-x64 -c Release
Hinweis: RuntimeIdentifier kann in der Projektdatei festgelegt werden.
Hinweis: ReadyToRun wird derzeit nur für eigenständige Anwendungen unterstützt . Es wird in einer späteren Ankündigung für Framework-abhängige Anwendungen hinzugefügt.
Die Generierung von Maschinenzeichen kann aktiviert werden, indem die PublishReadyToRunEmitSymbols Eigenschaft auf true . Sie müssen keine Maschinenzeichen für Debugging-Zwecke erstellen. Diese Zeichen sind nur für Profilierungszwecke nützlich.
Derzeit unterstützt das SDK eine Möglichkeit, bestimmte Assemblys von der Kompilierung in ReadyToRun-Images auszuschließen. Dies kann in Fällen nützlich sein, in denen Baugruppen nicht optimiert werden müssen, um die Leistung zu verbessern. Das Ausschließen von Baugruppen in diesem Fall kann dazu beitragen, die Größe der Anwendung zu verringern. Wenn der ReadyToRun-Compiler eine bestimmte Assembly nicht kompilieren kann, besteht die Lösung möglicherweise auch darin, sie zu entfernen.
Mit der Elementgruppe PublishReadyToRunExclude wird eine Ausnahme ausgelöst:
<ItemGroup> <PublishReadyToRunExclude Include="FilenameOfAssemblyToExclude.dll" /> </ItemGroup>
Plattformübergreifende / architektonische Zusammenstellung
Der ReadyToRun-Compiler unterstützt Cross-Targeting noch nicht. Sie müssen für ein bestimmtes Ziel kompilieren. Wenn Sie beispielsweise R2R-Images für Windows x64 benötigen, müssen Sie den Veröffentlichungsbefehl in dieser Umgebung ausführen.
Ausnahmen:
- Windows x64 kann zum Kompilieren der Windows-Images ARM32, ARM64 und x86 verwendet werden.
- Windows x86 kann zum Kompilieren von Windows ARM32-Images verwendet werden.
- Linux x64 kann zum Kompilieren der Linux-Images ARM32 und ARM64 verwendet werden.
Baugruppenlayout
Das NET Core 3.0 SDK enthält ein Tool, mit dem die Anwendungsgröße reduziert werden kann, indem IL analysiert und nicht verwendete Builds eliminiert werden.
Mit .NET Core können Sie jederzeit eigenständige Anwendungen veröffentlichen, die alles enthalten, was Sie zum Ausführen Ihres Codes benötigen, ohne .NET auf dem Bereitstellungsziel installieren zu müssen. In einigen Fällen erfordert die Anwendung nur eine kleine Teilmenge des Frameworks, und sie kann viel kleiner gemacht werden, indem nur die verwendeten Bibliotheken einbezogen werden.
Wir verwenden den IL-Builder , um die IL Ihrer Anwendung zu scannen, um festzustellen, welcher Code tatsächlich benötigt wird, und um dann nicht verwendete Framework-Bibliotheken auszuschließen. Dies kann die Größe einiger Anwendungen erheblich reduzieren. In der Regel profitieren kleine Konsolenanwendungen wie Tools am meisten, da sie häufig kleine Teilmengen des Frameworks verwenden und sich normalerweise gut zum Zuschneiden eignen.
Um dieses Tool zu verwenden, setzen Sie PublishTrimmed=true in Ihrem Projekt und veröffentlichen Sie die eigenständige Anwendung:
dotnet publish -r <rid> -c Release
Die Veröffentlichungsausgabe enthält eine Teilmenge der Infrastrukturbibliotheken, je nachdem, welcher Anwendungscode aufgerufen wird. Für die helloworld-Anwendung reduziert der Linker die Größe von ~ 68 MB auf ~ 28 MB.
Anwendungen oder Frameworks (einschließlich ASP.NET Core und WPF), die Reflection oder verwandte dynamische Funktionen verwenden, werden beim Zuschneiden häufig unterbrochen, da der Linker dieses dynamische Verhalten nicht kennt und normalerweise nicht bestimmen kann, welche Arten von Frameworks zur Reflektion zur Laufzeit erforderlich sind . Um solche Anwendungen zuzuschneiden, müssen Sie dem Linker alle Typen mitteilen, die für die Reflektion in Ihrem Code und in allen Paketen oder Umgebungen erforderlich sind, von denen Sie abhängig sind. Testen Sie Ihre Apps nach dem Zuschneiden.
Weitere Informationen zu IL Linker finden Sie in der Dokumentation oder im Mono / Linker- Repository.
Hinweis: In früheren Versionen von .NET Core wurde ILLink.Tasks als externes NuGet-Paket ausgeliefert und bot den größten Teil der gleichen Funktionalität. Es wird nicht mehr unterstützt - Upgrade auf die neueste Version 3.0 SDK.
Linker- und ReadToRun-Linker-Sharing
Linker Linker und ReadyToRun Linker können für dieselbe Anwendung verwendet werden. Im Allgemeinen verkleinert der Linker Ihre Anwendung, und der sofort einsatzbereite Compiler macht sie wieder etwas größer, jedoch mit einem erheblichen Leistungsgewinn. Es lohnt sich, verschiedene Konfigurationen zu testen, um die Auswirkungen der einzelnen Optionen zu verstehen.
Hinweis: dotnet / sdk # 3257 verhindert die gemeinsame Nutzung von Linkern und ReadyToRun für WPF- und Windows Forms-Anwendungen. Wir arbeiten daran, dies im Rahmen der .NET Core 3.0-Version zu beheben.
Native Hosting-Beispiel
Kürzlich wurde ein Native Hosting-Beispiel veröffentlicht . Es zeigt den besten Ansatz für das Hosten von .NET Core in einer nativen Anwendung.
Im Rahmen von .NET Core 3.0 bieten wir jetzt gemeinsame Funktionen für unsere eigenen .NET Core-Hostingdienste, die bisher nur für verwaltete .NET Core-Anwendungen über offiziell bereitgestellte .NET Core-Hostingdienste verfügbar waren. Die Funktionalität hängt hauptsächlich mit dem Laden der Baugruppe zusammen. Diese Funktionalität sollte es einfacher machen, eigene Hosting-Services zu erstellen, die alle .NET Core-Funktionen nutzen können.
HTTP / 2-Unterstützung in HttpClient
HTTP / 2 ist die Hauptversion des HTTP-Protokolls. Einige der bemerkenswerten Funktionen von HTTP / 2 sind die Unterstützung der Header-Komprimierung und vollständig gemultiplexte Streams über eine einzige Verbindung. Obwohl HTTP / 2 die Semantik von HTTP (HTTP-Header, -Methoden usw.) beibehält, unterscheidet es sich von HTTP / 1.x darin, wie Daten gesendet werden.
HttpClient unterstützt jetzt HTTP / 2-Anforderungen. Standardmäßig bleibt auch alles HTTP / 1.1, aber Sie können es zugunsten von HTTP / 2 deaktivieren, indem Sie die Version mithilfe einer HTTP-Anforderung installieren.
var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001") };
Alternativ können Sie standardmäßig HTTP / 2-Anforderungen senden, indem Sie DefaultRequestVersion auf HttpClient .
var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001"), DefaultRequestVersion = new Version(2, 0) };
Aufgrund dieser Änderung müssen sich Server und Clients auf die verwendete Protokollversion einigen. ALPN (Application-Layer Protocol Negotiation) ist eine TLS-Erweiterung, mit der Server und Client die im Rahmen ihrer Interaktion verwendete Protokollversion aushandeln können. Beachten Sie jedoch, dass die meisten Server nur ALPN als einzige Möglichkeit zum Herstellen einer HTTP / 2-Verbindung unterstützen. Daher wird HTTP / 2 von HttpClient nur über die TLS-Verbindung ausgehandelt.
In Entwicklungsszenarien können Sie, wenn Server und Client a priori wissen, dass beide HTTP / 2 ohne Verschlüsselung sprechen, eine HTTP / 2-Verbindung über Klartext herstellen, indem Sie den AppContext Schalter oder die Umgebungsvariable AppContext . ( DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1 ).
AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
Fertigstellung
Wir freuen uns sehr, wenn Sie neue Funktionen ausprobieren. Bitte melden Sie Probleme oder Fehler, die Sie finden. Sie können auch Anfragen für neue Funktionen senden, deren Implementierung jedoch bis zur nächsten Version warten muss.
Jetzt stehen wir kurz vor dem Abschluss der Arbeiten an der .NET Core 3.0-Komponente und lenken die Aufmerksamkeit des Teams auf die Verbesserung der Release-Qualität. Wir haben Monate vor Bugfixes und Leistungsverbesserungen.
Übrigens werden wir für das nächste größere Update die Hauptzweige in den .NET Core-Repositorys wechseln. Dies wird höchstwahrscheinlich unmittelbar nach Preview 7 im Juli geschehen.
Vielen Dank, dass Sie .NET Core 3.0 getestet haben. Wir bedanken uns für Ihre Hilfe. Im Moment konzentrieren wir uns darauf, die endgültige Version für Sie am interessantesten und qualitativ hochwertigsten zu machen.