dotnet pack

Ten artykuł dotyczy: ✔️ zestaw .NET Core 3.1 SDK i nowsze wersje

Nazwisko

dotnet pack - Pakuje kod do pakietu NuGet.

Streszczenie

dotnet pack [<PROJECT>|<SOLUTION>] [-c|--configuration <CONFIGURATION>]
    [--force] [--include-source] [--include-symbols] [--interactive]
    [--no-build] [--no-dependencies] [--no-restore] [--nologo]
    [-o|--output <OUTPUT_DIRECTORY>] [--runtime <RUNTIME_IDENTIFIER>]
    [-s|--serviceable] [--tl:[auto|on|off]] [-v|--verbosity <LEVEL>]
    [--version-suffix <VERSION_SUFFIX>]

dotnet pack -h|--help

opis

Polecenie dotnet pack kompiluje projekt i tworzy pakiety NuGet. Wynikiem tego polecenia jest pakiet NuGet (czyli plik nupkg ).

Jeśli chcesz wygenerować pakiet zawierający symbole debugowania, dostępne są dwie opcje:

  • --include-symbols — tworzy pakiet symboli.
  • --include-source — tworzy pakiet symboli z folderem zawierającym src pliki źródłowe.

Zależności NuGet spakowanego projektu są dodawane do pliku nuspec , więc są one prawidłowo rozwiązywane podczas instalowania pakietu. Jeśli spakowany projekt zawiera odwołania do innych projektów, inne projekty nie są uwzględnione w pakiecie. Obecnie musisz mieć pakiet dla każdego projektu, jeśli masz zależności między projektami.

Domyślnie dotnet pack najpierw kompiluje projekt. Jeśli chcesz uniknąć tego zachowania, przekaż --no-build tę opcję. Ta opcja jest często przydatna w scenariuszach kompilacji ciągłej integracji, w których wiesz, że kod został wcześniej skompilowany.

Uwaga

W niektórych przypadkach nie można wykonać niejawnej kompilacji. Taka sytuacja może wystąpić, gdy GeneratePackageOnBuild jest ustawiona, aby uniknąć cyklicznej zależności między obiektami docelowymi kompilacji i pakietów. Kompilacja może również zakończyć się niepowodzeniem, jeśli istnieje zablokowany plik lub inny problem.

Właściwości programu MSBuild można podać w dotnet pack poleceniu procesu pakowania. Aby uzyskać więcej informacji, zobacz Właściwości docelowe pakietu NuGet i dokumentacja wiersza polecenia MSBuild. W sekcji Przykłady pokazano, jak używać przełącznika MSBuild -p dla kilku różnych scenariuszy.

Uwaga

Projekty internetowe nie są pakowalne.

Niejawne przywracanie

Nie trzeba uruchamiaćdotnet restore, ponieważ jest ona uruchamiana niejawnie przez wszystkie polecenia, które wymagają przywrócenia, takie jak dotnet new, , dotnet build, dotnet rundotnet test, , dotnet publish, i dotnet pack. Aby wyłączyć niejawne przywracanie, użyj --no-restore opcji .

Polecenie dotnet restore jest nadal przydatne w niektórych scenariuszach, w których jawne przywracanie ma sens, takie jak kompilacje ciągłej integracji w usługach Azure DevOps Services lub w systemach kompilacji, które muszą jawnie kontrolować, kiedy nastąpi przywracanie.

Aby uzyskać informacje na temat zarządzania kanałami informacyjnymi NuGet, zobacz dokumentacjędotnet restore.

To polecenie obsługuje dotnet restore opcje przekazywane w długim formularzu (na przykład --source). Opcje formularza krótkiego, takie jak -s, nie są obsługiwane.

Pobieranie manifestu obciążenia

Po uruchomieniu tego polecenia inicjuje asynchroniczne pobieranie manifestów reklamowych dla obciążeń. Jeśli pobieranie jest nadal uruchomione po zakończeniu tego polecenia, pobieranie zostanie zatrzymane. Aby uzyskać więcej informacji, zobacz Manifesty reklamowe.

Argumenty

PROJECT | SOLUTION

Projekt lub rozwiązanie do spakowania. Jest to ścieżka do pliku csproj, vbproj lub fsproj albo do pliku lub katalogu rozwiązania. Jeśli nie zostanie określony, polecenie przeszukuje bieżący katalog dla projektu lub pliku rozwiązania.

Opcje

  • -c|--configuration <CONFIGURATION>

    Definiuje konfigurację kompilacji. Wartość domyślna dla większości projektów to Debug, ale można zastąpić ustawienia konfiguracji kompilacji w projekcie.

  • --force

    Wymusza rozwiązanie wszystkich zależności, nawet jeśli ostatnie przywracanie zakończyło się pomyślnie. Określenie tej flagi jest takie samo jak usunięcie pliku project.assets.json .

  • -?|-h|--help

    Wyświetla opis sposobu używania polecenia .

  • --include-source

    Zawiera symbole debugowania pakiety NuGet oprócz zwykłych pakietów NuGet w katalogu wyjściowym. Pliki źródeł znajdują się w folderze src w pakiecie symboli.

  • --include-symbols

    Zawiera symbole debugowania pakiety NuGet oprócz zwykłych pakietów NuGet w katalogu wyjściowym.

  • --interactive

    Umożliwia zatrzymanie polecenia i oczekiwanie na wprowadzenie lub działanie użytkownika. Na przykład w celu ukończenia uwierzytelniania. Dostępny od wersji .NET Core 3.0 SDK.

  • --no-build

    Nie kompiluje projektu przed pakowaniem. Ponadto niejawnie ustawia flagę --no-restore .

  • --no-dependencies

    Ignoruje odwołania do projektu i przywraca tylko projekt główny.

  • --no-restore

    Nie wykonuje niejawnego przywracania podczas uruchamiania polecenia.

  • --nologo

    Nie wyświetla baneru startowego ani wiadomości o prawach autorskich.

  • -o|--output <OUTPUT_DIRECTORY>

    Umieszcza wbudowane pakiety w określonym katalogu.

    • Zestaw .NET 7.0.200 SDK

      W zestawie SDK w wersji 7.0.200 jeśli określisz --output opcję podczas uruchamiania tego polecenia w rozwiązaniu, interfejs wiersza polecenia wyemituje błąd. Jest to regresja i została naprawiona w wersji 7.0.201 i nowszych wersji zestawu .NET SDK.

  • --runtime <RUNTIME_IDENTIFIER>

    Określa docelowe środowisko uruchomieniowe, dla których mają być przywracane pakiety. Aby uzyskać listę identyfikatorów środowiska uruchomieniowego (RID), zobacz wykaz identyfikatorów RID.

  • -s|--serviceable

    Ustawia flagę z możliwością obsługi w pakiecie. Aby uzyskać więcej informacji, zobacz Blog platformy .NET: .NET Framework 4.5.1 obsługuje Aktualizacje zabezpieczeń firmy Microsoft dla bibliotek NuGet platformy .NET.

  • --tl:[auto|on|off]

    Określa, czy rejestrator terminalu ma być używany dla danych wyjściowych kompilacji. Wartość domyślna to auto, która najpierw weryfikuje środowisko przed włączeniem rejestrowania terminalu. Sprawdzanie środowiska sprawdza, czy terminal może korzystać z nowoczesnych funkcji wyjściowych i nie używa przekierowanych standardowych danych wyjściowych przed włączeniem nowego rejestratora. on Pomija sprawdzanie środowiska i włącza rejestrowanie terminalu. off Pomija sprawdzanie środowiska i używa domyślnego rejestratora konsoli.

    Rejestrator terminalu pokazuje fazę przywracania, po której następuje faza kompilacji. W każdej fazie obecnie projekty budowlane są wyświetlane w dolnej części terminalu. Każdy projekt, który tworzy, generuje dane wyjściowe zarówno docelowy programu MSBuild, który jest obecnie kompilowany, jak i ilość czasu spędzonego na tym obiekcie docelowym. Możesz wyszukać te informacje, aby dowiedzieć się więcej o kompilacji. Po zakończeniu kompilowania projektu zostanie napisana pojedyncza sekcja "ukończona kompilacja", która przechwytuje:

    • Nazwa utworzonego projektu.
    • Struktura docelowa (jeśli jest przeznaczona dla wielu celów).
    • Stan tej kompilacji.
    • Podstawowe dane wyjściowe tej kompilacji (która jest hiperlinkowana).
    • Każda diagnostyka wygenerowana dla tego projektu.

    Ta opcja jest dostępna począwszy od platformy .NET 8.

  • -v|--verbosity <LEVEL>

    Ustawia poziom szczegółowości polecenia. Dozwolone wartości to q[uiet], , n[ormal]m[inimal], d[etailed], i diag[nostic]. W celu uzyskania więcej informacji, zobacz następujący temat: LoggerVerbosity.

  • --version-suffix <VERSION_SUFFIX>

    Definiuje wartość właściwości VersionSuffix MSBuild. Wpływ tej właściwości na wersję pakietu zależy od wartości Version właściwości i VersionPrefix , jak pokazano w poniższej tabeli:

    Właściwości z wartościami Wersja pakietu
    Brak 1.0.0
    Version $(Version)
    VersionPrefix Tylko $(VersionPrefix)
    VersionSuffix Tylko 1.0.0-$(VersionSuffix)
    VersionPrefix i VersionSuffix $(VersionPrefix)-$(VersionSuffix)

    Jeśli chcesz użyć polecenia --version-suffix, określ VersionPrefix plik projektu, a nie Version w pliku projektu. Na przykład jeśli VersionPrefix element ma 0.1.2 wartość i zostanie przekazana --version-suffix rc.1 do dotnet packelementu , wersja pakietu będzie mieć wartość 0.1.2-rc.1.

    Jeśli Version ma wartość i przekazujesz --version-suffix do dotnet packelementu , wartość określona dla --version-suffix parametru jest ignorowana.

Przykłady

  • Spakuj projekt w bieżącym katalogu:

    dotnet pack
    
  • Spakuj app1 projekt:

    dotnet pack ~/projects/app1/project.csproj
    
  • Spakuj projekt w bieżącym katalogu i umieść wynikowe pakiety w folderze nupkgs :

    dotnet pack --output nupkgs
    
  • Spakuj projekt w bieżącym katalogu do nupkgs folderu i pomiń krok kompilacji:

    dotnet pack --no-build --output nupkgs
    
  • Przy użyciu sufiksu wersji projektu skonfigurowanego tak jak <VersionSuffix>$(VersionSuffix)</VersionSuffix> w pliku csproj spakuj bieżący projekt i zaktualizuj wynikowej wersji pakietu przy użyciu danego sufiksu:

    dotnet pack --version-suffix "ci-1234"
    
  • Ustaw wersję pakietu na 2.1.0 wartość z właściwością PackageVersion MSBuild:

    dotnet pack -p:PackageVersion=2.1.0
    
  • Spakuj projekt dla określonej platformy docelowej:

    dotnet pack -p:TargetFrameworks=net45
    
  • Spakuj projekt i użyj określonego środowiska uruchomieniowego (Windows 10) dla operacji przywracania:

    dotnet pack --runtime win10-x64
    
  • Spakuj projekt przy użyciu pliku nuspec :

    dotnet pack ~/projects/app1/project.csproj -p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget
    

    Aby uzyskać informacje o sposobie używania NuspecFileelementów , NuspecBasePathi NuspecProperties, zobacz następujące zasoby: