Dela via

dotnet pack

  • Artikel

Den här artikeln gäller för: ✔️ .NET Core 3.1 SDK och senare versioner

Name

dotnet pack – Packar koden i ett NuGet-paket.

Sammanfattning

dotnet pack [<PROJECT>|<SOLUTION>] [--artifacts-path <ARTIFACTS_DIR>]
    [-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

beskrivning

Kommandot dotnet pack skapar projektet och skapar NuGet-paket. Resultatet av det här kommandot är ett NuGet-paket (dvs. en .nupkg-fil ).

Om du vill generera ett paket som innehåller felsökningssymbolerna har du två tillgängliga alternativ:

  • --include-symbols - det skapar symbolpaketet.
  • --include-source – det skapar symbolpaketet med en src mapp inuti som innehåller källfilerna.

NuGet-beroenden för det paketerade projektet läggs till i .nuspec-filen , så de löses korrekt när paketet installeras. Om det packade projektet har referenser till andra projekt ingår inte de andra projekten i paketet. För närvarande måste du ha ett paket per projekt om du har beroenden mellan projekt.

Som standard dotnet pack skapar projektet först. Om du vill undvika det här beteendet skickar du alternativet --no-build . Det här alternativet är ofta användbart i scenarier med kontinuerlig integrering (CI) där du vet att koden skapades tidigare.

Kommentar

I vissa fall kan inte den implicita versionen utföras. Detta kan inträffa när GeneratePackageOnBuild anges för att undvika ett cykliskt beroende mellan bygg- och paketmål. Bygget kan också misslyckas om det finns en låst fil eller något annat problem.

Du kan ange MSBuild-egenskaper för dotnet pack kommandot för förpackningsprocessen. Mer information finns i NuGet-paketmålegenskaper och MSBuild-kommandoradsreferensen. I avsnittet Exempel visas hur du använder MSBuild-växeln -p för ett par olika scenarier.

Kommentar

Webbprojekt är inte packbara.

Implicit återställning

Du behöver inte köra dotnet restore eftersom den körs implicit av alla kommandon som kräver en återställning, till exempel dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishoch dotnet pack. Om du vill inaktivera implicit återställning använder du alternativet --no-restore .

Kommandot dotnet restore är fortfarande användbart i vissa scenarier där det är meningsfullt att uttryckligen återställa, till exempel kontinuerliga integreringsversioner i Azure DevOps Services eller i byggsystem som uttryckligen behöver styra när återställningen sker.

Information om hur du hanterar NuGet-feeds finns i dokumentationendotnet restore.

Det här kommandot stöder alternativen dotnet restore när det skickas i det långa formuläret (till exempel --source). Korta formuläralternativ, till exempel -s, stöds inte.

Nedladdningar av arbetsbelastningsmanifest

När du kör det här kommandot initieras en asynkron bakgrundsnedladdning av annonseringsmanifest för arbetsbelastningar. Om nedladdningen fortfarande körs när det här kommandot är klart stoppas nedladdningen. Mer information finns i Annonseringsmanifest.

Argument

PROJECT | SOLUTION

Projektet eller lösningen som ska packas. Det är antingen en sökväg till en csproj-, vbproj- eller fsproj-fil eller till en lösningsfil eller katalog. Om det inte anges söker kommandot i den aktuella katalogen efter ett projekt eller en lösningsfil.

Alternativ

  • --artifacts-path <ARTIFACTS_DIR>

    Alla build-utdatafiler från det körda kommandot kommer att gå i undermappar under den angivna sökvägen, avgränsade med projekt. Mer information finns i Artefaktutdatalayout. Tillgänglig sedan .NET 8 SDK.

  • -c|--configuration <CONFIGURATION>

    Definierar byggkonfigurationen. Om du utvecklar med .NET 8 SDK eller en senare version använder kommandot konfigurationen Release som standard för projekt vars TargetFramework är inställt på net8.0 eller en senare version. Standardkonfigurationen är Debug för tidigare versioner av SDK och för tidigare målramverk. Du kan åsidosätta standardinställningen i projektinställningar eller med det här alternativet. Mer information finns i "dotnet publish" använder versionskonfiguration och "dotnet pack" använder versionskonfiguration.

  • --force

    Tvingar alla beroenden att lösas även om den senaste återställningen lyckades. Att ange den här flaggan är detsamma som att ta bort project.assets.json-filen.

  • -?|-h|--help

    Skriver ut en beskrivning av hur du använder kommandot.

  • --include-source

    Innehåller felsökningssymbolerna NuGet-paket utöver de vanliga NuGet-paketen i utdatakatalogen. Källfilerna src ingår i mappen i symbolpaketet.

  • --include-symbols

    Innehåller felsökningssymbolerna NuGet-paket utöver de vanliga NuGet-paketen i utdatakatalogen.

  • --interactive

    Tillåter att kommandot stoppar och väntar på användarens indata eller åtgärd. Till exempel för att slutföra autentiseringen. Tillgänglig sedan .NET Core 3.0 SDK.

  • --no-build

    Skapar inte projektet innan det packas. Den anger --no-restore också implicit flaggan.

  • --no-dependencies

    Ignorerar projekt-till-projekt-referenser och återställer bara rotprojektet.

  • --no-restore

    Kör inte en implicit återställning när kommandot körs.

  • --nologo

    Visar inte startbanderollen eller upphovsrättsmeddelandet.

  • -o|--output <OUTPUT_DIRECTORY>

    Placerar de inbyggda paketen i den angivna katalogen.

    • .NET 7.0.200 SDK

      Om du anger --output alternativet när du kör det här kommandot på en lösning i 7.0.200 SDK genererar CLI ett fel. Detta är en regression och har åtgärdats i 7.0.201 och senare versioner av .NET SDK.

  • --runtime <RUNTIME_IDENTIFIER>

    Anger den målkörning som paketen ska återställas för. En lista över Runtime-identifierare (RID) finns i RID-katalogen.

  • -s|--serviceable

    Anger den servicebara flaggan i paketet. Mer information finns i .NET-bloggen: .NET Framework 4.5.1 Stöder Microsoft Security Uppdateringar för .NET NuGet-bibliotek.

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

    Anger om terminalloggaren ska användas för byggutdata. Standardvärdet är auto, som först verifierar miljön innan du aktiverar terminalloggning. Miljökontrollen verifierar att terminalen kan använda moderna utdatafunktioner och inte använder en omdirigerad standardutdata innan den nya loggaren aktiveras. on hoppar över miljökontrollen och aktiverar terminalloggning. off hoppar över miljökontrollen och använder standardkonsolloggaren.

    Terminalloggaren visar återställningsfasen följt av byggfasen. Under varje fas visas de pågående byggprojekten längst ned i terminalen. Varje projekt som skapar utdata både det MSBuild-mål som för närvarande skapas och hur lång tid som spenderas på det målet. Du kan söka efter den här informationen om du vill veta mer om bygget. När ett projekt är färdigt skrivs ett enda "build completed"-avsnitt som samlar in:

    • Namnet på det skapade projektet.
    • Målramverket (om det är flera mål).
    • Status för bygget.
    • Den primära utdatan för den versionen (som är hyperlänkad).
    • Diagnostik som genereras för projektet.

    Det här alternativet är tillgängligt från och med .NET 8.

  • -v|--verbosity <LEVEL>

    Anger kommandots verbositetsnivå. Tillåtna värden är q[uiet], m[inimal], n[ormal], d[etailed]och diag[nostic]. Mer information finns i LoggerVerbosity.

  • --version-suffix <VERSION_SUFFIX>

    Definierar värdet för VersionSuffix egenskapen MSBuild. Effekten av den här egenskapen på paketversionen beror på värdena Version för egenskaperna och VersionPrefix , som du ser i följande tabell:

    Egenskaper med värden Paketversion
    Ingen 1.0.0
    Version $(Version)
    VersionPrefix Bara $(VersionPrefix)
    VersionSuffix Bara 1.0.0-$(VersionSuffix)
    VersionPrefix och VersionSuffix $(VersionPrefix)-$(VersionSuffix)

    Om du vill använda --version-suffixanger VersionPrefix och inte Version i projektfilen. Om till exempel VersionPrefix är 0.1.2 och du skickar --version-suffix rc.1 till dotnet packblir 0.1.2-rc.1paketversionen .

    Om Version har ett värde och du skickar --version-suffix till dotnet packignoreras det angivna värdet.--version-suffix

Exempel

  • Packa projektet i den aktuella katalogen:

    dotnet pack

  • Packa projektet app1 :

    dotnet pack ~/projects/app1/project.csproj

  • Packa projektet i den aktuella katalogen och placera de resulterande paketen nupkgs i mappen:

    dotnet pack --output nupkgs

  • Packa projektet i den aktuella katalogen i nupkgs mappen och hoppa över byggsteget:

    dotnet pack --no-build --output nupkgs

  • Med projektets versionssuffix konfigurerat som <VersionSuffix>$(VersionSuffix)</VersionSuffix> i .csproj-filen packar du det aktuella projektet och uppdaterar den resulterande paketversionen med det angivna suffixet:

    dotnet pack --version-suffix "ci-1234"

  • Ange paketversionen till 2.1.0 med PackageVersion egenskapen MSBuild:

    dotnet pack -p:PackageVersion=2.1.0

  • Packa projektet för ett specifikt målramverk:

    dotnet pack -p:TargetFrameworks=net45

  • Packa projektet och använd en specifik körning (Windows) för återställningsåtgärden:

    dotnet pack --runtime win-x64

  • Packa projektet med hjälp av en .nuspec-fil :

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

    Information om hur du använder NuspecFile, NuspecBasePathoch NuspecProperties, finns i följande resurser: