"dotnet pack" używa konfiguracji wydania

  • Artykuł

Poleceniedotnet pack, które pakuje kod do pakietu NuGet, teraz używa Release konfiguracji zamiast Debug konfiguracji domyślnie.

Poprzednie zachowanie

Wcześniej użyto konfiguracji, dotnet pack chyba że konfiguracja została określona jawnie lub PackRelease została ustawiona na true.Debug

Właściwość PackRelease została dodana na platformie .NET 7 jako ścieżka do tej zmiany powodującej niezgodność. Wcześniej można było ustawić zmienną DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS środowiskową do użycia PackRelease w projekcie, który był częścią rozwiązania programu Visual Studio.

Nowe zachowanie

Jeśli programujesz przy użyciu zestawu .NET 8 SDK lub nowszej wersji, dotnet pack domyślnie używa Release konfiguracji dla wszystkich projektów. Jeśli masz skrypt ciągłej integracji/ciągłego wdrażania, testy lub kod, w którym kod został zakodowany Debug na stałe w ścieżce wyjściowej, ta zmiana może spowodować przerwanie przepływu pracy. Ponadto nie będzie można debugować spakowanej aplikacji, chyba że Debug konfiguracja została jawnie określona (na przykład przy użyciu polecenia dotnet pack --configuration Debug.

dotnet pack program może jednocześnie spakować wiele obiektów docelowych monikers (TFM). Jeśli projekt jest przeznaczony dla wielu wersji i masz różne PackRelease wartości dla różnych obiektów docelowych, może to spowodować konflikt, w którym niektóre serwery TFM spakują Release konfigurację, a inne spakują konfigurację Debug .

W przypadku projektów w rozwiązaniu:

  • dotnet pack program może spakować wszystkie projekty w rozwiązaniu programu Visual Studio, jeśli zostanie podany plik rozwiązania. Dla każdego projektu w rozwiązaniu wartość PackRelease jest niejawnie ustawiona na true , jeśli jest niezdefiniowana. Aby dotnet pack określić poprawną konfigurację do użycia, wszystkie projekty w rozwiązaniu muszą wyrazić zgodę na ich wartość PackRelease.

  • Ta zmiana może spowodować regresję dotnet pack wydajności, zwłaszcza w przypadku rozwiązań zawierających wiele projektów. Aby rozwiązać ten problem, wprowadzono nową zmienną środowiskową DOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS .

  • Zmienna DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS środowiskowa nie jest już rozpoznawana.

Wprowadzona wersja

.NET 8 (wersja zapoznawcza 1)

Typ zmiany powodującej niezgodność

Ta zmiana może mieć wpływ na zgodność źródła i jest również zmianą behawioralną.

Przyczyna wprowadzenia zmiany

W większości przypadków podczas tworzenia pakietu chcesz, aby kod był optymalizowany i może zachować mniejszy pakiet, wykluczając informacje debugowania.

Zmienna DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS środowiskowa została usunięta, ponieważ włączone zachowanie jest teraz zachowaniem domyślnym, a szczegółowa kontrolka nie jest już konieczna.

  • Aby całkowicie wyłączyć nowe zachowanie, możesz ustawić zmienną DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE środowiskową na true (lub dowolną inną wartość). Ta zmienna ma wpływ zarówno na , jak dotnet publish i dotnet pack.

  • Aby jawnie określić konfigurację Debug pakowania, użyj -c opcji lub --configuration z opcją dotnet pack.

  • Jeśli potok ciągłej integracji/ciągłego wdrażania jest uszkodzony z powodu zakodowanych na stałe ścieżek wyjściowych, zaktualizuj ścieżki Release zamiast Debug, wyłącz nowe zachowanie przy użyciu DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE zmiennej środowiskowej lub określ, czy Debug konfiguracja powinna być używana.

  • Jeśli pakujesz rozwiązanie i jest ono uszkodzone, ponieważ co najmniej jeden projekt jawnie ustawia wartość dla PackReleaseelementu , należy jawnie ustawić PackReleasefalse wartość w każdym projekcie:

    <PropertyGroup>
  <PackRelease>false</PackRelease>
</PropertyGroup>

  • Jeśli pakujesz rozwiązanie i wydajność uległa pogorszeniu, możesz ustawić DOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS zmienną środowiskową na true (lub dowolną inną wartość), aby usunąć regresję. Jeśli używasz tej zmiennej i dowolnego projektu definiujesz PackRelease, wszystkie projekty muszą ją zdefiniować lub można użyć pliku Directory.Build.Props . Ta zmienna ma wpływ zarówno na , jak dotnet publish i dotnet pack.

Zobacz też