Neuerungen im SDK und Tools für .NET 11

In diesem Artikel werden neue Features und Verbesserungen im .NET SDK für .NET 11 beschrieben. Es wurde zuletzt für Preview 7 aktualisiert. Sie können .NET 11 hier herunterladen.

SDK-Speicherbedarf

Die Größe des .NET SDK-Installers unter Linux und macOS wurde durch Deduplizieren von Assemblys mithilfe symbolischer Verknüpfungen reduziert. Duplikate .dll und .exe Dateien werden durch Inhaltshash identifiziert und durch symbolische Verknüpfungen ersetzt, die auf eine einzelne Kopie verweisen. Dies betrifft Tarballs, .pkg, .deb und .rpm-Installationsprogramme.

Die Analyse hat festgestellt, dass 35% des SDK-Verzeichnisses aus doppelten Dateien besteht. Unter Linux x64 beträgt dies 816 Dateien insgesamt 140 MB auf dem Datenträger (53 MB komprimiert). Durch das Ersetzen von Duplikaten durch symbolische Verknüpfungen sinkt das Linux x64-Archiv erheblich in der Größe:

Plattform SDK-Komponente .NET 10 Größe (MB) .NET 11 Vorschau 2 Größe (MB) Reduzierung
linux-x64 Tarball 230 189 17.8%
linux-x64 1_i386.deb 164 122 25.6%
linux-x64 rpm 165 122 26.0%
linux-x64 Container Variiert Variiert 8–17%

Das SDK wird weiter gekürzt, da crossgen für Assemblys übersprungen wird, die ausschließlich unter DotnetTools/ vorhanden sind. Für Assemblys, die auch außerhalb von DotnetTools/ vorhanden sind, wird crossgen weiterhin ausgeführt. Sie profitieren von einem schnelleren Start, und das Duplikat wird anschließend entfernt. Assemblys jedoch, die nur in DotnetTools/ vorkommen, bleiben als reine IL erhalten. Auf einem linux-x64 Build reduziert dies den SDK-Tarball um zusätzliche 23,6 MB.

Die Windows-Deduplizierung ist für eine zukünftige Vorschau geplant.

Codeanalyse und -warnungen

Verbesserungen der Codeanalyse

CA1873: Reduziertes Rauschen und verbesserte Nachrichten

Zwei Verbesserungen wurden an CA1873 vorgenommen (Vermeidung der potenziell teuren Protokollierung):

Weniger Fehlalarme: Zugriff auf Eigenschaften, GetType(), GetHashCode() und GetTimestamp()-Aufrufe werden nicht mehr als Fehler markiert. Die Diagnosefunktionen gelten nun standardmäßig nur noch für die Protokollierung auf der Informationsebene und darunter, da Warnungs-, Fehler- und kritische Codepfade selten zu den am häufigsten auftretenden Pfaden gehören.

Spezifische Gründe in Diagnosenachrichten: Die Diagnosenachricht enthält jetzt, warum ein Argument gekennzeichnet wurde, wodurch Sie priorisieren können, welche Warnungen adressiert werden sollen:

// Before
warning CA1873: Evaluation of this argument may be expensive and unnecessary if logging is disabled

// After
warning CA1873: Evaluation of this argument may be expensive and unnecessary if logging is disabled (method invocation)

Die neun spezifischen Gründe sind:

  • Methodenaufruf
  • Objekterstellung
  • Arrayerstellung
  • Boxing-Konvertierung
  • Zeichenfolgeninterpolierung
  • Sammlungsausdruck
  • Erstellung anonymer Objekte
  • Await-Ausdruck
  • Mit Ausdruck

Analyzer-Fehlerkorrekturen

Analyzer Reparatur
CA1515 Ein falsch positives Ergebnis wurde behoben, wenn C#-Erweiterungselemente vorhanden sind
CA1034 Ein falsch positives Ergebnis wurde behoben, wenn C#-Erweiterungselemente vorhanden sind
CA1859 Falsche Behandlung von Standardschnittstellenimplementierungen wurde behoben

AnalysisLevel korrigiert für .NET 11

Projekte mit AnalysisLevel=latest verwendeten fälschlicherweise die .NET 9-Analyseregeln anstelle der erwarteten .NET 11-Analyseregeln. Dieses Problem wurde behoben.

Neue SDK-Warnungen

NETSDK1235: Benutzerdefinierte .nuspec mit PackAsTool

Eine neue Warnung wird ausgegeben, wenn ein Projekt PackAsTool=true setzt und eine benutzerdefinierte NuspecFile-Eigenschaft angibt. Toolpakete erfordern bestimmte Layout- und Bezeichnerkonventionen, die in der Regel gegen benutzerdefinierte .nuspec Dateien verstoßen:

warning NETSDK1235: .NET Tools do not support using a custom .nuspec file, but the nuspec file 'custom.nuspec' was provided. Remove the NuspecFile property from this project to enable packing it as a .NET Tool.

Der Packvorgang wird weiterhin mit einer Warnung fortgesetzt, um Beschädigungen bestehender Projekte zu vermeiden.

CLI-Workflow und Entwicklerproduktivität

Lösungsfilter-CLI-Unterstützung

dotnet sln kann jetzt Lösungsfilter (.slnf) direkt über die CLI erstellen und bearbeiten. Mit Lösungsfiltern können große Repositorys eine Teilmenge von Projekten laden oder erstellen, ohne die Hauptlösung zu ändern. Die unterstützten Vorgänge spiegeln die vorhandenen dotnet sln Befehle wieder:

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj
dotnet sln MyApp.slnf list
dotnet sln MyApp.slnf remove src/Lib/Lib.csproj

Apps, die auf Dateien basieren und über mehrere Dateien verteilt sind

Dateibasierte Apps unterstützen jetzt eine #:include Direktive, sodass Sie freigegebene Hilfsprogramme in separate Dateien verschieben können, ohne den dateibasierten Workflow aufzugeben:

#:include helpers.cs
#:include models/customer.cs

Console.WriteLine(Helpers.FormatOutput(new Customer()));

Übergeben von Umgebungsvariablen mit dotnet run

dotnet run -e KEY=VALUE übergibt Umgebungsvariablen über die Befehlszeile an die gestartete App, ohne dass Sie shell-Status exportieren oder Startprofile bearbeiten müssen:

dotnet run -e ASPNETCORE_ENVIRONMENT=Development -e LOG_LEVEL=Debug

Auf diese Weise übergebene Umgebungsvariablen stehen MSBuild-Logik als RuntimeEnvironmentVariable Elemente zur Verfügung.

Verbesserungen von dotnet watch

.NET 11 bringt mehrere dotnet watch Verbesserungen für lang andauernde lokale Entwicklungszyklen:

  • Aspire Integration:dotnet watch Kann jetzt mit Aspire App-Hosts integriert werden, was Workflows mit Hot-Reload-Funktionalität im gesamten Aspire Anwendungsmodell ermöglicht.
  • Wiederherstellung bei Abstürzen: Wenn die App abstürzt, wird sie von dotnet watch bei der nächsten relevanten Dateiänderung automatisch neu gestartet.
  • Windows Desktop-Support: Die Strg+C-Behandlung wird für Windows-Desktop-Apps wie Windows Forms und WPF verbessert.

.NET 11 fügt auch die Geräteauswahl für MAUI- und mobile Projekte hinzu. Nachdem Sie ein Zielframework ausgewählt haben, dotnet watch ruft das ComputeAvailableDevices MSBuild-Ziel auf, wählt automatisch aus, wenn ein einzelnes Gerät vorhanden ist, und zeigt eine interaktive Auswahl mit der Suche an, wenn mehrere vorhanden sind. Das ausgewählte Gerät wird an dotnet build und den gestarteten Unterprozess dotnet run weitergegeben, einschließlich einer erneuten Wiederherstellung, wenn das Gerät einen RuntimeIdentifier erfordert, der bei der ursprünglichen Wiederherstellung nicht vorhanden war.

Um ein Gerät über die Befehlszeile vorab auszuwählen, verwenden Sie Folgendes:

dotnet watch --device <device-id>

Die folgenden langfristigen dotnet watch Probleme wurden behoben:

  • Die Aufforderung zur Framework-Auswahl scheint nicht mehr festzuhängen, weil zwei Leser beide Console.ReadKey() aufrufen.
  • STRG+C und STRG+R zeigen beim Abbruch des WebSocket-Transports nicht mehr fälschlicherweise WebSocketException bzw. ObjectDisposedException an.
  • Hot Reload tritt auf iOS nicht mehr in einen Deadlock, wenn UIKitSynchronizationContext installiert ist, bevor der Start-Hook ausgeführt wird.

Hinweis

dotnet watch erfordert <MtouchLink>None</MtouchLink> in der .csproj-Datei für iOS-Simulator-Projekte. Siehe dotnet/macios #25295.

Fish-Shell-Abschlüsse

Der Fish-Shell-Anbieter gab zuvor einen Einzeiler aus, der jede Vervollständigung an einen dynamischen Aufruf von dotnet complete delegierte. Das generierte Skript führt nun die tokenisierte Befehlszeile durch, gibt statische Fertigstellungen für Unterbefehle, Optionen und Positionsargumente aus und greift nur bei Bedarf auf dynamische Aufrufe zurück. Dies entspricht dem Verhalten der Bash-, Zsh- und PowerShell-Anbieter.

dotnet-Referenz greift auf aktuelles Verzeichnis zurück

dotnet reference add und dotnet reference remove greifen jetzt auf das aktuelle Verzeichnis zurück, wenn kein --project angegeben ist, entsprechend dem langjährigen Verhalten von dotnet reference list:

cd ClassLib2
dotnet reference add ../ClassLib1/ClassLib1.csproj   # now works without --project
dotnet reference remove ../ClassLib1/ClassLib1.csproj

Zuvor schlugen diese Befehle mit Could not find project or directory '' fehl, wenn sie in einem Verzeichnis ausgeführt wurden, das eine Projektdatei enthielt.

Unterstützung für "dotnet reference" für dateibasierte Apps

dotnet reference unterstützt jetzt dateibasierte Apps. Hier können Sie dotnet reference add --file app.cs <project-path> Direktiven direkt zu Ihrer dateibasierten App hinzufügen #:project und diese Verweise verwenden dotnet reference list und dotnet reference remove verwalten.

Hinweis zu den Starteinstellungen nach stderr verschoben

Die Informationsmeldung „Startoptionen aus ... verwenden“ wird jetzt in stderr statt in stdout geschrieben. Skripte, die die Standardausgabe von dotnet run erfassen, müssen diese Zeile nicht mehr entfernen.

Weitere CLI-Verbesserungen

  • dotnet format akzeptiert jetzt --framework für mehrzielige Projekte.
  • dotnet test im MTP-Modus (Microsoft Testing Platform) unterstützt jetzt --artifacts-path.
  • dotnet tool exec und dnx fordern beim Ausführen von Tools keine zusätzliche Bestätigung mehr an.
  • dotnet nuget <subcommand> --help leitet jetzt korrekt an die Hilfeausgabe der NuGet CLI weiter, anstatt auf generische Hilfe zurückzugreifen.
  • dotnet publish entfernt bei nachfolgenden Ausführungen der Single-File-Veröffentlichung keine nativen DLLs mehr.

Webressourcen und Telemetrie

Objektgruppen für statische Webressourcen

Das Static Web Assets SDK unterstützt Ressourcengruppen, eine Möglichkeit, Gruppen zusammengehöriger Ressourcen zu definieren, die Veröffentlichungs-, Fingerabdruckerstellungs- und Endpunktmetadaten gemeinsam nutzen. Die zugehörige DefineStaticWebAssetEndpoints Aufgabe erhält einen AdditionalEndpointDefinitions Parameter, und der Glob-Matcher macht den erfassten ** Stamm verfügbar, sodass zusätzliche Endpunkte (z. B. Standarddokumentrouten wie / für **/index.html) deklarativ definiert werden können.

Dies ist die Infrastruktur für ASP.NET Core Komponentenautoren und SDK-Erweiterungsautoren. Die meisten App-Entwickler sehen das Ergebnis indirekt daran, dass Razor- und Blazor-Komponentenpakete mit bereinigteren Metadaten für statische Ressourcen ausgeliefert werden.

OpenTelemetry ersetzt Application Insights für CLI-Telemetrie

Die dotnet CLI verwendet jetzt OpenTelemetry (OTel) mit Azure Monitor und OTLP-Exportern für die Opt-In-Telemetrie, wobei die vorherige Microsoft.ApplicationInsights Abhängigkeit ersetzt wird. Das für den Benutzer sichtbare Verhalten bleibt unverändert – dieselbe Telemetrie wird erfasst, mit derselben Opt-out-Möglichkeit über DOTNET_CLI_TELEMETRY_OPTOUT. Die Motivation besteht darin, die CLI NativeAOT-freundlich zu machen.

CLI-Architektur

NativeAOT-Einstiegspunkt für die .NET CLI

Um den nahezu sofortigen Start für häufige CLI-Aufrufe zu aktivieren, aktiviert .NET 11 jetzt standardmäßig den nativen CLI-kompilierten dotnet CLI-Host. Sie können dies deaktivieren, indem Sie die Einstellung festlegen DOTNET_CLI_ENABLEAOT=false. Die verwalteten und nativeAOT-Parser teilen eine Implementierung, sodass der AOT-Pfad analysiert, überprüft und für jeden Befehl gerendert --help wird.

Befehle, die vollständig ohne verwaltete Laufzeit ausgeführt werden können, werden nativ ausgeführt. Jeder andere Befehl fällt transparent auf die verwaltete CLI zurück. Die folgenden Befehle werden vollständig über den AOT-Pfad bereitgestellt:

  • dotnet --version, dotnet --infodotnet --help
  • dotnet <command> --help für jeden integrierten Befehl
  • dotnet --cli-schema
  • dotnet sln list, dotnet sln migratedotnet sln remove

Aufrufe von Tools und externen Befehlen (globale Tools, PATH-Befehle, App-Basisbefehle) werden nun ebenfalls über den AOT-Pfad aufgelöst und außerhalb des Prozesses gestartet, wodurch der 600–700-ms-Start der verwalteten CLI für Befehle wie dotnet ef oder dotnet dev-certs übersprungen wird.

OpenTelemetry-Tracing-Spans werden aus dem AOT-Pfad mit korrekten Eltern-/Kind-Beziehungen zu den verwalteten CLI-Spans ausgegeben und ermöglichen eine durchgängige Analyse verteilter Traces über beide Hosts hinweg.

MSBuild-Server standardmäßig aktiviert

Der MSBuild-Server ist jetzt standardmäßig aktiviert. Dadurch wird ein warmer MSBuild-Worker zwischen CLI-Aufrufen beibehalten, wodurch der Startaufwand für wiederholte Build- und Testbefehle reduziert wird. Um dies zu deaktivieren, legen DOTNET_CLI_USE_MSBUILD_SERVER=false Sie fest oder MSBUILDUSESERVER=0.

Teilweise Ausführungsbereitschaft für vorgelagerte Tools

Eine neue MSBuild-Eigenschaft ermöglicht es übergeordneten Tools (z. B. dotnet/macios und dotnet/maui), eine Liste von Assemblies zu deklarieren, die teilweise R2R-kompiliert und vom Composite-Image ausgeschlossen werden sollen. Das zugrunde liegende Szenario besteht darin, generierten XAML-Code in Debug-Builds vorzukompilieren, um den F5-Start zu beschleunigen, ohne die vollen Crossgen-Kosten für den Rest der App in Kauf nehmen zu müssen. App-Entwickelnde legen diese Eigenschaft nicht direkt fest – sie ist ein Hook, den mobile Workloads in ihren Zielen nutzen.

Testverbesserungen

Dotnet-Testverbesserungen

.NET 11 fügt mehrere Funktionen hinzudotnet test, wenn sie über Microsoft Testplattform (MTP) ausgeführt werden:

  • --no-dependencies: Überspringt das Erstellen von Projekt-zu-Projekt-Verweisen und entspricht dem vorhandenen dotnet build --no-dependencies Verhalten.
  • DOTNET_TEST_RUNNER Umgebungsvariable: Wählt den Testläufer aus, ohne dass eine global.json Änderung erforderlich ist. Legen Sie den Wert für die aktuelle Sitzung auf VSTest oder Microsoft.Testing.Platform fest, um global.json zu überschreiben.
  • --use-current-runtime / --ucr: Zielt während Restore und Build auf die aktuelle Runtime ab und entspricht damit der Option, die bereits für dotnet build und dotnet publish verfügbar ist.
  • --test-modules Ausschlussmuster: Muster, die beginnen, ! werden jetzt als Ausgeschlossene behandelt, und Leerzeichen zwischen Semikolons werden gekürzt, sodass YAML-gefaltete CI-Ausdrücke ordnungsgemäß funktionieren.
  • Testanzahl pro Assembly: Die Zusammenfassungszeile für Ausführungen mit mehreren Assemblies enthält jetzt die jeweilige Testanzahl pro Assembly.
  • Terminalprotokollierungsargumente: --tl, --terminallogger, und --tlp werden jetzt an MSBuild weitergeleitet, anstatt als Testanwendungsargumente übergeben zu werden.
  • Liveanzeige von In-Flight-Tests: Der Statusbereich zeigt Tests an, die ausgeführt werden, mithilfe eines neuen TestInProgressMessages IPC-Ereignisses. Das Bedienfeld behält das Trimmen pro Assembly für große parallele Ausführungen bei und ist nur in interaktiven ANSI-Terminals aktiviert.
  • Zweistufiger Abbruch mit Strg+C: Beim ersten Drücken wird das Einplanen neuer Test-Apps gestoppt und ein Hinweis angezeigt; beim zweiten Drücken werden alle untergeordneten Testprozesse zwangsweise beendet.
  • --device für MAUI: Wählen Sie ein Gerät pro Zielframework aus, wenn Sie Tests für .NET MAUI Projekte ausführen.
  • Protokoll 1.1.0-Ausgabeweiterleitung: Wenn der Testhost Protokoll 1.1.0 unterstützt, werden stdout/stderr und IOutputDevice Nachrichten live über den Terminalreporter gestreamt, anstatt nur bei Fehlern angezeigt zu werden.

Richtlinienoptionen auf Dotnet-Testausführungsebene

dotnet testunterstützt jetzt Ausführungsebenen --timeout und --maximum-failed-tests Optionen im Microsoft Testplattformmodus. Mit diesen Optionen können Sie lange oder laute Ausführungen für mehrere Projekte konsistent beenden.

dotnet test support for traversal projects

dotnet test unterstützt Microsoft.Build.Traversal jetzt Projekte. Das SDK erweitert traversale Diagramme, dedupliziert wiederholte Verweise und führt Tests für den aggregierten Projektsatz aus.

Dotnet Test Reporter und Artefakte Verbesserungen

Reporter- und Artefaktbehandlung wurde für Mehrmodulläufe verbessert, einschließlich erwarteter und tatsächlicher Rendering in fehlerausgabe, Volllauf-Zero-Test-Bewertungslogik und automatische Nachbearbeitung kompatibler Testartefakte.

Testvorlagen unterstützen xUnit v3 und NUnit auf Microsoft. Testing.Platform

Die integrierte xunit Vorlage fügt eine --xunit-version Option hinzu. Verwenden Sie v3, um ein xUnit v3-Projekt zu generieren, das standardmäßig Microsoft.Testing.Platform als Runner verwendet:

dotnet new xunit --xunit-version v3
dotnet new xunit --xunit-version v3 --test-runner VSTest

Die nunit Vorlage fügt ebenfalls eine --test-runner Option hinzu, um Microsoft.Testing.Platform zu verwenden:

dotnet new nunit --test-runner Microsoft.Testing.Platform

Beide Optionen stehen für C#-, F#- und VB-Vorlagen zur Verfügung.

Container- und Toolupdates

Container-Builds für mehrere Architekturen mit Podman

Die integrierte Containerveröffentlichung des SDK unterstützt jetzt das Erstellen von Containerimages mit mehreren Architekturen, wenn Podman als Containermodul verwendet wird. Zuvor mussten Multi-Arch-Builds Docker verwenden. Dadurch werden stammlose Multi-Arch-Workflows für Linux-Distributionen aufgehoben, die Podman standardmäßig versenden.

Plattformeigene auswahl lokaler Containerlaufzeit

Die Containerveröffentlichung bevorzugt jetzt plattformeigene lokale Laufzeiten, wenn verfügbar: wslc auf Windows und container unter macOS. Docker und Podman bleiben Fallbacks. Um eine Laufzeit zu erzwingen, legen Sie das LocalRegistry Projekt explizit fest, oder veröffentlichen Sie das Profil.

TypeScript-Ausgaben lassen sich in statische Webressourcen integrieren

Projekte, die Microsoft.TypeScript.MSBuild in Razor-Klassenbibliotheken verwenden, integrieren jetzt die Ausgabe der TypeScript-Kompilierung ordnungsgemäß in die statischen Webressourcen von ASP.NET Core. Die neue Integration bindet die TypeScript-Ausgaben nach der Kompilierung in die Pipeline für statische Webressourcen ein und ermöglicht so Komprimierung, Fingerabdruckbildung und korrektes Verhalten bei Neuerstellungen. Zuvor konnten Neuerstellungsvorgänge fehlschlagen, weil TypeScript-Ausgabedateien entweder vor der Kompilierung erkannt wurden oder nach dem Bereinigen veraltete Referenzen bestehen blieben.

MSBuild-Server- und OpenTelemetry-Umgebungsvariablen

Die dotnet CLI unterdrückt den MSBuild-Buildserver nicht mehr, wenn DOTNET_CLI_USE_MSBUILD_SERVER dies nicht festgelegt ist. Zuvor schrieb die CLI bedingungslos MSBUILDUSESERVER=0 und überschrieb dabei jeden benutzerdefinierten Wert. Wenn DOTNET_CLI_USE_MSBUILD_SERVER nicht gesetzt ist, lässt die CLI MSBUILDUSESERVER unverändert, sodass Sie den MSBuild-Server direkt aktivieren können.

Der OTLP-Telemetrie-Exporter ist jetzt auch aktiviert, wenn eine beliebige standardmäßige OpenTelemetry-Umgebungsvariable vorhanden ist (OTEL_EXPORTER_OTLP_*Endpunkt, Protokoll, Header oder Timeout, einschließlich signalspezifischer _TRACES_*- und _METRICS_*-Varianten), zusätzlich zur vorhandenen DOTNET_CLI_TELEMETRY_ENABLE_EXPORTER-Flag.

Einschließen von DLLs in dateibasierte Apps

Dateibasierte Apps können jetzt kompilierte DLL-Verweise mit #:include ohne Feature-Flag einschließen. Die Standardmäßige Elementtypzuordnung behandelt .dll Dateien als Reference Elemente, sodass Sie direkt auf vordefinierte Bibliotheken verweisen können:

#:include ./libs/MyLibrary.dll

MyLibrary.Helper.DoWork();

Darüber hinaus dürfen jetzt weitere #:-Direktiven dateiübergreifend in eingebundenen Dateien doppelt vorkommen, wenn ihre Werte übereinstimmen (#:sdk, #:property, #:package). Dadurch sind in sich geschlossene Bibliotheksdateien möglich, die ihre eigenen Abhängigkeiten deklarieren, ohne Konflikte zu verursachen, wenn sie von mehreren Einstiegspunkten eingebunden werden.

Siehe auch

  • Last updated on