Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här artikeln gäller för: ✔️ .NET 6 SDK och senare versioner
Namn
dotnet pack – Packar koden i ett NuGet-paket.
Sammanfattning
dotnet pack [<PROJECT>|<SOLUTION>]
[--artifacts-path <ARTIFACTS_DIR>] [-c|--configuration <CONFIGURATION>]
[--disable-build-servers] [--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
Description
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 ensrcmapp 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.
Anmärkning
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 Målegenskaper för NuGet-paket och MSBuild Command-Line-referens. I avsnittet Exempel visas hur du använder MSBuild-växeln -p för ett par olika scenarier.
Anmärkning
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.
Arguments
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.
Options
--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
Releasekonfiguration som standard för projekt vars TargetFramework är inställt pånet8.0eller en senare version. Standardkonfigurationen för bygget ärDebugfö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.
--disable-build-serversTvingar kommandot att ignorera alla beständiga byggservrar. Det här alternativet är ett konsekvent sätt att inaktivera all användning av cachelagring av versioner, vilket tvingar fram en version från grunden. En version som inte förlitar sig på cacheminnen är användbar när cacheminnena kan vara skadade eller felaktiga av någon anledning. Tillgänglig sedan .NET 7 SDK.
--forceTvingar 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.
--include-sourceInnehåller felsökningssymbolerna NuGet-paket utöver de vanliga NuGet-paketen i utdatakatalogen. Källfilerna
srcingår i mappen i symbolpaketet.--include-symbolsInnehåller felsökningssymbolerna NuGet-paket utöver de vanliga NuGet-paketen i utdatakatalogen.
--interactiveTillåter att kommandot stoppar och väntar på användarens indata eller åtgärd. Till exempel för att slutföra autentiseringen.
--no-buildSkapar inte projektet innan det packas. Den anger
--no-restoreockså implicit flaggan.--no-dependenciesIgnorerar projekt-till-projekt-referenser och återställer bara rotprojektet.
--no-restoreKör inte en implicit återställning när kommandot körs.
--nologoVisar 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
--outputalternativet 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|--serviceableAnger den servicebara flaggan i paketet. Mer information finns i .NET-blogg: .NET Framework 4.5.1 Stöder Microsoft-säkerhetsuppdateringar för .NET NuGet-bibliotek.
--tl:[auto|on|off]Anger om Terminal Logger 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.onhoppar över miljökontrollen och aktiverar terminalloggning.offhoppar över miljökontrollen och använder standardkonsolloggaren.TerminalLogger 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]ochdiag[nostic]. Mer information finns i LoggerVerbosity.
--version-suffix <VERSION_SUFFIX>Definierar värdet för
VersionSuffixegenskapen MSBuild. Effekten av den här egenskapen på paketversionen beror på värdenaVersionför egenskaperna ochVersionPrefix, som du ser i följande tabell:Egenskaper med värden Paketversion None 1.0.0Version$(Version)VersionPrefixbara$(VersionPrefix)VersionSuffixbara1.0.0-$(VersionSuffix)VersionPrefixochVersionSuffix$(VersionPrefix)-$(VersionSuffix)Om du vill använda
--version-suffixangerVersionPrefixoch inteVersioni projektfilen. Om till exempelVersionPrefixär0.1.2och du skickar--version-suffix rc.1tilldotnet packblir0.1.2-rc.1paketversionen .Om
Versionhar ett värde och du skickar--version-suffixtilldotnet packignoreras det angivna värdet.--version-suffix
-?|-h|--helpSkriver ut en beskrivning av hur du använder kommandot.
Examples
Packa projektet i den aktuella katalogen:
dotnet packPacka projektet
app1:dotnet pack ~/projects/app1/project.csprojPacka projektet i den aktuella katalogen och placera de resulterande paketen
nupkgsi mappen:dotnet pack --output nupkgsPacka projektet i den aktuella katalogen i
nupkgsmappen och hoppa över byggsteget:dotnet pack --no-build --output nupkgsMed 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.0medPackageVersionegenskapen MSBuild:dotnet pack -p:PackageVersion=2.1.0Packa projektet för ett specifikt målramverk:
dotnet pack -p:TargetFrameworks=net45Packa projektet och använd en specifik körning (Windows) för återställningsåtgärden:
dotnet pack --runtime win-x64Packa projektet med hjälp av en .nuspec-fil :
dotnet pack ~/projects/app1/project.csproj -p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nugetInformation om hur du använder
NuspecFile,NuspecBasePathochNuspecProperties, finns i följande resurser: