Neuerungen im SDK und Tooling für .NET 8

In diesem Artikel werden neue Features im .NET SDK und Tools für .NET 8 beschrieben.

SDK

Dieser Abschnitt enthält folgende Unterabschnitte:

• CLI-basierte Projektbewertung
• Terminalbuildausgabe
• Vereinfachte Ausgabepfade
• Befehl „dotnet workload clean“
• „dotnet publish“- und „dotnet pack“-Objekte
• Vorlagen-Engine
• Quelllink
• Source-build SDK

CLI-basierte Projektbewertung

MSBuild enthält eine neue Funktion, welche die Integration von Daten aus MSBuild in Ihre Skripts oder Tools erleichtert. Die folgenden neuen Flags sind für CLI-Befehle wie dotnet publish verfügbar, um Daten zur Verwendung in CI-Pipelines und an anderer Stelle abzurufen.

Werte werden in die Standardausgabe geschrieben. Mehrere oder komplexe Werte werden als JSON ausgegeben, wie in den folgenden Beispielen gezeigt.

>dotnet publish --getProperty:OutputPath
bin\Release\net8.0\

>dotnet publish -p PublishProfile=DefaultContainer --getProperty:GeneratedContainerDigest --getProperty:GeneratedContainerConfiguration
{
  "Properties": {
    "GeneratedContainerDigest": "sha256:ef880a503bbabcb84bbb6a1aa9b41b36dc1ba08352e7cd91c0993646675174c4",
    "GeneratedContainerConfiguration": "{\u0022config\u0022:{\u0022ExposedPorts\u0022:{\u00228080/tcp\u0022:{}},\u0022Labels\u0022...}}"
  }
}

>dotnet publish -p PublishProfile=DefaultContainer --getItem:ContainerImageTags
{
  "Items": {
    "ContainerImageTags": [
      {
        "Identity": "latest",
        ...
    ]
  }
}

Terminalbuildausgabe

dotnet build verfügt über eine neue Option zum Erstellen einer moderneren Buildausgabe. Diese Ausgabe der Terminalprotokollierung gruppiert Fehler unter dem Projekt, aus dem sie stammen, unterscheidet die verschiedenen Zielframeworks für Projekte mit mehreren Zielen besser und liefert Echtzeitinformationen dazu, was beim Build ausgeführt wird. Um die neue Ausgabe zu aktivieren, verwenden Sie die Option --tl. Weitere Informationen zu dieser Option finden Sie unter dotnet-Buildoptionen.

Vereinfachte Ausgabepfade

In .NET 8 wurde eine Option eingeführt, mit der der Ausgabepfad und die Ordnerstruktur für Buildausgaben vereinfacht werden können. Bisher haben .NET-Apps umfassende und komplexe Ausgabepfade für verschiedene Buildartefakte erstellt. Mit der neuen, vereinfachten Ausgabepfadstruktur werden alle Buildausgaben an einem gemeinsamen Speicherort erfasst, wodurch Tools diesen leichter finden.

Weitere Informationen finden Sie unter Artefakte – Ausgabelayout.

dotnet workload clean-Befehl

In .NET 8 wurde ein neuer Befehl zum Bereinigen von Workloadpaketen eingeführt, die möglicherweise nach mehreren .NET SDK- oder Visual Studio-Updates übrig bleiben. Wenn beim Verwalten von Workloads Probleme auftreten, sollten Sie workload clean verwenden, um sicher einen bekannten Zustand wiederherzustellen, bevor Sie es erneut versuchen. Der Befehl hat zwei Modi:

• dotnet workload clean

  Führt eine Workload-Garbage Collection für dateibasierte oder MSI-basierte Workloads aus, wodurch verwaiste Pakete bereinigt werden. Verwaiste Pakete stammen aus deinstallierten Versionen des .NET SDK oder aus Paketen, bei denen keine Installationsdatensätze für das Paket mehr vorhanden sind.

  Wenn Visual Studio installiert ist, listet der Befehl auch alle Workloads auf, die Sie mithilfe von Visual Studio manuell bereinigen sollten.

• dotnet workload clean --all

  Dieser Modus ist gründlicher und bereinigt jedes Paket auf dem Computer, das den aktuellen SDK-Workloadinstallationstyp aufweist (und das nicht von Visual Studio stammt). Außerdem werden alle Workloadinstallationsdatensätze für das ausgeführte .NET SDK-Featureband und darunter entfernt.

Ressourcen von dotnet publish und dotnet pack

Da mit den Befehlen dotnet publish und dotnet pack Produktionsressourcen erstellt werden sollen, erzeugen sie jetzt standardmäßig Release-Ressourcen.

Die folgende Ausgabe zeigt das unterschiedliche Verhalten zwischen dotnet build und dotnet publish, und wie Sie zur Veröffentlichung von Debug-Ressourcen zurückkehren können, indem Sie die PublishRelease-Eigenschaft auf false festlegen.

/app# dotnet new console
/app# dotnet build
  app -> /app/bin/Debug/net8.0/app.dll
/app# dotnet publish
  app -> /app/bin/Release/net8.0/app.dll
  app -> /app/bin/Release/net8.0/publish/
/app# dotnet publish -p:PublishRelease=false
  app -> /app/bin/Debug/net8.0/app.dll
  app -> /app/bin/Debug/net8.0/publish/

Weitere Informationen finden Sie unter ‚dotnet pack‘ verwendet die Releasekonfiguration und ‚dotnet publish‘ verwendet die Releasekonfiguration.

Sicherheitsüberwachung für dotnet restore

Ab .NET 8 können Sie sicherheitsrelevante Überprüfungen auf bekannte Sicherheitsrisiken aktivieren, wenn Abhängigkeitspakete wiederhergestellt werden. Diese Überwachung erstellt einen Bericht zu Sicherheitsrisiken mit dem Namen des betroffenen Pakets, dem Schweregrad des Sicherheitsrisikos und einem Link zu Empfehlungen und weiteren Details. Wenn Sie dotnet add oder dotnet restore ausführen, werden die Warnungen NU1901–NU1904 für alle gefundenen Sicherheitsrisiken angezeigt. Weitere Informationen finden Sie unter Überwachen auf Sicherheitsrisiken.

Vorlagen-Engine

Die Vorlagen-Engine bietet in .NET 8 noch mehr Sicherheit, indem einige sicherheitsrelevante Features von NuGet integriert werden. Die Verbesserungen umfassen:

• Verhinderung des standardmäßigen Herunterladens von Paketen aus http://-Feeds. Beispielsweise kann der folgende Befehl das Vorlagenpaket nicht installieren, da die Quell-URL kein HTTPS verwendet.

  dotnet new install console --add-source "http://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json"

  Sie können diese Einschränkung mit dem Flag --force außer Kraft setzen.

• Überprüfung von dotnet new, dotnet new install und dotnet new update auf bekannte Sicherheitsrisiken im Vorlagenpaket. Wenn Sicherheitsrisiken gefunden werden und Sie fortfahren möchten, müssen Sie das Flag --force verwenden.

• Angabe von Informationen zum Vorlagenpaketbesitzer für dotnet new. Der Besitz wird über das NuGet-Portal überprüft und kann als vertrauenswürdiges Merkmal angesehen werden.

• Angabe für dotnet search und dotnet uninstall, ob eine Vorlage aus einem Paket installiert wird, das als „vertrauenswürdig“ gilt, d. h., es verwendet ein reserviertes Präfix.

SourceLink

Source Link ist jetzt im .NET SDK enthalten. Ziel ist, dass mehr Pakete diese Informationen standardmäßig enthalten, indem Source Link in das SDK integriert wird, anstatt einen separaten <PackageReference> für das Paket anzufordern. Diese Informationen verbessern die IDE-Benutzeroberfläche für Entwickler.

Source-build SDK

Das Linux distribution-built (source-build) SDK bietet jetzt die Möglichkeit, eigenständige Anwendungen mit den source-build-Runtimepaketen zu erstellen. Das distributionsspezifische Runtimepaket ist mit dem source-build SDK gebündelt. Während der eigenständigen Bereitstellung wird auf dieses gebündelte Runtimepaket verwiesen, wodurch das Feature für Benutzer aktiviert wird.

Unterstützung von nativem AOT

Die Option zum Veröffentlichen als Native AOT wurde erstmals in .NET 7 eingeführt. Beim Veröffentlichen einer App mit Native AOT wird eine vollständig eigenständige Version Ihrer App erstellt, die keine Runtime benötigt. Alles ist in einer einzelnen Datei enthalten. .NET 8 bietet die folgenden Verbesserungen für die Native AOT-Veröffentlichung:

• Unterstützung für die x64- und Arm64-Architekturen unter macOS

• Reduziert die Größen von Native AOT-Apps unter Linux bis zu 50 %. Die folgende Tabelle zeigt die Größe einer „Hallo Welt“-App, die mit Native AOT veröffentlicht wird, die die gesamte .NET Runtime in .NET 7 im Vergleich zu .NET 8 enthält:

  Betriebssystem	.NET 7	.NET 8
  Linux x64 (mit -p:StripSymbols=true)	3,76 MB	1,84 MB
  Windows x64	2,85 MB	1,77 MB

• Möglichkeit zur Angabe einer Optimierungseinstellung: Größe oder Geschwindigkeit. Standardmäßig entscheidet sich der Compiler für das Generieren von schnellem Code, aber unter Beachtung der Größe der Anwendung. Sie können jedoch die <OptimizationPreference>-Eigenschaft von MSBuild verwenden, um speziell für das eine oder das andere zu optimieren. Weitere Informationen finden Sie unter Optimieren von AOT-Bereitstellungen.

Konsolen-App-Vorlage

Die Standardvorlage für Konsolen-Apps bietet jetzt standardmäßig Unterstützung für AOT. Führen Sie einfach dotnet new console --aot aus, um ein Projekt zu erstellen, das für die AOT-Kompilierung konfiguriert ist. Die von --aot hinzugefügte Projektkonfiguration hat drei Auswirkungen:

• Sie generiert eine native, eigenständige ausführbare Datei mit Native AOT, wenn Sie das Projekt veröffentlichen, z. B. mit dotnet publish oder Visual Studio.
• Sie ermöglicht Kompatibilitätsanalysetools für Kürzungen, AOT und einzelne Dateien. Diese Analysetools warnen Sie bei potenziell problematischen Teilen Ihres Projekts (sofern vorhanden).
• Sie aktiviert die Debugzeitemulation von AOT, damit Sie beim Debuggen Ihres Projekts ohne AOT-Kompilierung eine ähnliche Erfahrung wie bei AOT erhalten. Wenn Sie beispielsweise in einem NuGet-Paket System.Reflection.Emit verwenden, das nicht für AOT kommentiert wurde (und daher vom Kompatibilitätsanalysetool übersehen wurde), sind dank der Emulation vor Überraschungen geschützt, wenn Sie versuchen, das Projekt mit AOT zu veröffentlichen.

iOS-ähnliche Plattformen mit Native AOT als Ziel

.NET 8 beginnt mit der Aktivierung der Native AOT-Unterstützung für iOS-ähnliche Plattformen. Sie können jetzt .NET iOS- und .NET MAUI-Anwendungen mit Native AOT auf folgenden Plattformen erstellen und ausführen:

• ios
• iossimulator
• maccatalyst
• tvos
• tvossimulator

Vorläufige Tests zeigen, dass die Größe der App auf dem Datenträger bei .NET iOS-Apps, die Native AOT anstelle von Mono-Kompilierung verwenden, um etwa 35 % abnimmt. Die App-Größe auf dem Datenträger für .NET MAUI iOS-Apps nimmt um bis zu 50 % ab. Darüber hinaus ist die Startzeit ebenfalls schneller. .NET iOS-Apps haben eine um etwa 28 % schnellere Startzeit, während .NET MAUI iOS-Apps im Vergleich zu Mono eine um etwa 50 % bessere Startleistung aufweisen. Die .NET 8-Unterstützung ist experimentell und nur der erste Schritt für das Feature insgesamt. Weitere Informationen finden Sie im Blogbeitrag „.NET 8-Leistungsverbesserungen in .NET MAUI“.

Native AOT-Unterstützung ist als Opt-In-Feature für die App-Bereitstellung verfügbar. Mono ist weiterhin die Standardlaufzeit für die App-Entwicklung und -Bereitstellung. Verwenden Sie „dotnet workload install maui“ zum Erstellen und Ausführen einer .NET MAUI-Anwendung mit Native AOT auf einem iOS-Gerät, um den .NET MAUI-Workload zu installieren, und „dotnet new maui -n HelloMaui“, um die App zu erstellen. Legen Sie dann in der Projektdatei die MSBuild-Eigenschaft „PublishAot“ auf „true“ fest.

<PropertyGroup>
  <PublishAot>true</PublishAot>
</PropertyGroup>

Wenn Sie die erforderliche Eigenschaft festlegen und „dotnet publish“ ausführen wie im folgenden Beispiel gezeigt, wird die App mithilfe von Native AOT bereitgestellt.

dotnet publish -f net8.0-ios -c Release -r ios-arm64  /t:Run

Begrenzungen

Nicht alle iOS-Funktionen sind mit Native AOT kompatibel. Auf ähnliche Weise sind nicht alle häufig in iOS verwendeten Bibliotheken mit nativer AOT-Kompilierung kompatibel. Zusätzlich zu den vorhandenen Einschränkungen der Native AOT-Bereitstellung werden in der folgenden Liste einige der weiteren Einschränkungen für iOS-ähnliche Plattformen aufgeführt:

• Die Verwendung von Native AOT ist nur während der App-Bereitstellung (dotnet publish) aktiviert.
• Das Debuggen von verwaltetem Code wird nur mit Mono-Kompilierung unterstützt.
• Die Kompatibilität mit .NET MAUI Framework ist eingeschränkt.

AOT-Kompilierung für Android-Apps

Um die App-Größe zu verringern, verwenden .NET- und .NET MAUI-Apps für Android den profilierten Kompilierungsmodus (Ahead-of-Time, AOT), wenn sie im Releasemodus integriert sind. Die profilierte AOT-Kompilierung wirkt sich auf weniger Methoden als die normale AOT-Kompilierung aus. .NET 8 führt die Eigenschaft <AndroidStripILAfterAOT> ein, mit der Sie die AOT-Kompilierung für Android-Apps aktivieren können, um die App-Größe noch weiter zu verringern.

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
</PropertyGroup>

Standardmäßig überschreibt die Einstellung von AndroidStripILAfterAOT auf true die Standardeinstellung AndroidEnableProfiledAot, sodass (fast) alle Methoden, die AOT-kompiliert wurden, gekürzt werden können. Sie können auch profiliertes AOT- und IL-Stripping zusammen verwenden, indem Sie beide Eigenschaften explizit auf truefestlegen:

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
  <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>

Integrierte Windows-Apps

Wenn Sie Apps erstellen, die Windows auf Nicht-Windows-Plattformen verwenden, wird die resultierende ausführbare Datei jetzt mit allen angegebenen Win32-Ressourcen aktualisiert, z. B. Anwendungssymbol, Manifest und Versionsinformationen.

Bisher mussten Anwendungen auf Windows erstellt werden, um über solche Ressourcen zu verfügen. Das Beheben dieser Lücke bei der bauübergreifenden Unterstützung war eine beliebte Anforderung, da es sich um einen erheblichen Schmerzpunkt handelte, der sowohl die Komplexität der Infrastruktur als auch die Ressourcennutzung beeinflusste.

.NET auf Linux

Mindestunterstützungsbaselines für Linux

Die Mindestunterstützungsbaselines für Linux wurden für .NET 8 aktualisiert. .NET wird mit Ubuntu 16.04 als Ziel für alle Architekturen erstellt. Dies ist in erster Linie wichtig, um die Mindestversion von glibc für .NET 8 zu definieren. .NET 8 kann bei Distributionsversionen, die eine ältere glibc enthalten, wie Ubuntu 14.04 oder Red Hat Enterprise Linux 7, nicht gestartet werden.

Weitere Informationen finden Sie unter Unterstützung für die Red Hat Enterprise Linux-Familie.

Erstellen Ihres eigenen .NET unter Linux

In früheren .NET-Versionen konnten Sie .NET aus der Quelle erstellen, aber dafür mussten Sie einen „Quell-Tarball“ aus dem Commit des Repositorys dotnet/installer erstellen, was einem Release entsprach. In .NET 8 ist dies nicht mehr erforderlich, und Sie können .NET unter Linux direkt aus dem Repository dotnet/dotnet erstellen. Dieses Repository verwendet dotnet/source-build, um .NET Runtimes, -Tools und -SDKs zu erstellen. Dies ist derselbe Build, den Red Hat und Canonical zum Erstellen von .NET verwenden.

Das Erstellen in einem Container ist für die meisten Personen der einfachste Ansatz, da die dotnet-buildtools/prereqs-Containerimages alle erforderlichen Abhängigkeiten enthalten. Weitere Informationen finden Sie in den Buildanweisungen.

NuGet-Signaturüberprüfung

Ab .NET 8 überprüft NuGet standardmäßig signierte Pakete unter Linux. NuGet überprüft auch weiterhin signierte Pakete unter Windows.

Die meisten Benutzer*innen sollten die Überprüfung nicht bemerken. Wenn Sie jedoch über ein vorhandenes Stammzertifikatpaket unter /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem verfügen, können Fehler bei Vertrauensstellungen mit der Warnung NU3042 auftreten.

Sie können die Überprüfung deaktivieren, indem Sie die Umgebungsvariable DOTNET_NUGET_SIGNATURE_VERIFICATION auf false festlegen.

Codeanalyse

.NET 8 bietet mehrere neue Codeanalysetools und Korrekturregeln, mit denen Sie überprüfen können, ob Sie .NET-Bibliotheks-APIs ordnungsgemäß und effizient nutzen. Die folgende Tabelle enthält eine Übersicht über die neuen Analysetools.

Diagnostik

C# Hot Reload unterstützt das Ändern von generischen Elementen.

Ab .NET 8 unterstützt C# Hot Reload das Ändern generischer Typen und generischer Methoden. Wenn Sie Konsolen-, Desktop-, Mobile- oder WebAssembly-Anwendungen mit Visual Studio debuggen, können Sie Änderungen auf generische Klassen und generische Methoden im C#-Code oder in Razor Pages anwenden. Weitere Informationen finden Sie in der vollständigen Liste der von Roslyn unterstützten Bearbeitungen.

Siehe auch

• Neuerungen in .NET 8