Freigeben über


„dotnet pack“ verwendet die Release-Konfiguration.

Der Befehl dotnet pack, der Code in ein NuGet-Paket packt, verwendet jetzt standardmäßig die Konfiguration Release anstelle der Debug-Konfiguration.

Vorheriges Verhalten

Zuvor hatte dotnet pack die Debug-Konfiguration verwendet, es sei denn, die Konfiguration wurde explizit angegeben, oder PackRelease wurde auf true festgelegt.

Die PackRelease-Eigenschaft wurde in .NET 7 als Pfadweiterleitung zu diesem Breaking Change hinzugefügt. Zuvor konnten Sie die Umgebungsvariable DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS auf die Verwendung von PackRelease in einem Projekt festlegen, das Teil einer Visual Studio-Projektmappe war.

Neues Verhalten

Wenn Sie mit dem .NET 8 SDK oder einer höheren Version entwickeln, verwendet dotnet pack die Release-Konfiguration standardmäßig für alle Projekte. Wenn Sie über ein CI/CD-Skript, Tests oder Code verfügen, in dem Sie Debug in einem Ausgabepfad hartcodiert haben, kann diese Änderung Ihren Workflow unterbrechen. Außerdem können Sie eine gepackte App nur debuggen, wenn die Debug-Konfiguration explizit angegeben wurde (z. B. mit dotnet pack --configuration Debug).

dotnet pack kann für mehrere Zielframeworkmoniker (TFM) gleichzeitig packen. Wenn Ihr Projekt auf mehrere Versionen abzielt, und Sie verschiedene PackRelease-Werte für unterschiedliche Ziele haben, kann es zu einem Konflikt führen, bei dem einige TFMs die Release-Konfiguration packen, während andere die Debug-Konfiguration packen.

Für Projekte in einer Projektmappe:

  • dotnet pack kann alle Projekte in einer Visual Studio-Projektmappe packen, wenn eine Projektmappendatei angegeben wird. Für jedes Projekt in der Projektmappe wird der Wert von PackRelease implizit auf true festgelegt, wenn er nicht definiert ist. Damit dotnet pack die richtige zu verwendende Konfiguration ermitteln kann, müssen sich alle Projekte in der Projektmappe auf den Wert von PackRelease einigen.

  • Diese Änderung kann dazu führen, dass die Leistung von dotnet pack sinkt, insbesondere bei Projektmappen, die viele Projekte enthalten. Um dies zu beheben, wurde die neue Umgebungsvariable DOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS eingeführt.

  • Die DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS-Umgebungsvariable ist nicht mehr gültig.

Eingeführt in Version

.NET 8 Preview 1

Typ des Breaking Changes

Diese Änderung kann sich auf die Quellkompatibilität auswirken und ist außerdem eine Verhaltensänderung (Behavior Change).

Grund für die Änderung

In den meisten Fällen, wenn Sie ein Paket erstellen, möchten Sie, dass Ihr Code optimiert wird, und das Paket kann kleiner gehalten werden, indem Debuginformationen ausgeschlossen werden.

Die Umgebungsvariable DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS wurde entfernt, da das von ihr ermöglichte Verhalten nun das Standardverhalten ist, weshalb die präzise Steuerung nicht mehr erforderlich ist.

  • Um das neue Verhalten vollständig zu deaktivieren, können Sie die Umgebungsvariable DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE auf true (oder einen anderen Wert) festlegen. Diese Variable wirkt sich sowohl auf dotnet publish als auch auf dotnet pack aus.

  • Um die Debug-Konfiguration für das Packen explizit anzugeben, verwenden Sie die Option -c oder --configuration mit dotnet pack.

  • Wenn Ihre CI/CD-Pipeline aufgrund hartcodierter Ausgabepfade unterbrochen wird, aktualisieren Sie die Pfade auf Release anstelle von Debug, deaktivieren Sie das neue Verhalten mithilfe der Umgebungsvariablen DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE, oder geben Sie an, dass die Debug-Konfiguration verwendet werden soll.

  • Wenn Sie eine Projektmappe packen und diese beschädigt ist, weil ein oder mehrere Projekte explizit einen Wert für PackRelease festlegen, sollten Sie PackRelease in jedem Projekt explizit auf false festlegen:

    <PropertyGroup>
      <PackRelease>false</PackRelease>
    </PropertyGroup>
    
  • Wenn Sie eine Lösung packen und die Leistung gesunken ist, können Sie die Umgebungsvariable DOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS auf true (oder einen anderen Wert) festlegen, um den Leistungsabfall zu beseitigen. Wenn Sie diese Variable verwenden und ein Projekt PackRelease definiert, müssen alle Projekte dies definieren, oder Sie können eine Directory.Build.Props-Datei verwenden. Diese Variable wirkt sich sowohl auf dotnet publish als auch auf dotnet pack aus.

Weitere Informationen