dotnet pack

Artikel
04/06/2024

Dit artikel is van toepassing op: ✔️ .NET Core 3.1 SDK en latere versies

Naam

dotnet pack - Verpakt de code in een NuGet-pakket.

Samenvatting

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

Beschrijving

Met de dotnet pack opdracht wordt het project gebouwd en NuGet-pakketten gemaakt. Het resultaat van deze opdracht is een NuGet-pakket (een .nupkg-bestand ).

Als u een pakket wilt genereren dat de foutopsporingssymbolen bevat, zijn er twee opties beschikbaar:

--include-symbols - het symboolpakket wordt gemaakt.
--include-source - hiermee wordt het symboolpakket gemaakt met een src map in die de bronbestanden bevat.

NuGet-afhankelijkheden van het verpakte project worden toegevoegd aan het .nuspec-bestand , zodat ze correct worden opgelost wanneer het pakket is geïnstalleerd. Als het verpakte project verwijzingen naar andere projecten bevat, worden de andere projecten niet opgenomen in het pakket. Op dit moment moet u per project een pakket hebben als u project-naar-project-afhankelijkheden hebt.

dotnet pack Standaard wordt het project eerst gebouwd. Als u dit gedrag wilt voorkomen, geeft u de --no-build optie door. Deze optie is vaak handig in CI-buildscenario's (Continuous Integration), waarbij u weet dat de code eerder is gebouwd.

Notitie

In sommige gevallen kan de impliciete build niet worden uitgevoerd. Dit kan gebeuren wanneer GeneratePackageOnBuild deze is ingesteld, om een cyclische afhankelijkheid tussen build- en packdoelen te voorkomen. De build kan ook mislukken als er een vergrendeld bestand of ander probleem is.

U kunt MSBuild-eigenschappen aan de dotnet pack opdracht voor het verpakkingsproces opgeven. Zie de doeleigenschappen van het NuGet-pakket en de MSBuild-opdrachtregelreferentie voor meer informatie. In de sectie Voorbeelden ziet u hoe u de MSBuild-switch -p gebruikt voor een aantal verschillende scenario's.

Notitie

Webprojecten kunnen niet worden verpakt.

Impliciete herstelbewerking

U hoeft niet uit te voeren dotnet restore omdat deze impliciet wordt uitgevoerd door alle opdrachten waarvoor een herstelbewerking moet worden uitgevoerd, zoals dotnet new, dotnet build, , dotnet run, dotnet test, , en dotnet publish.dotnet pack Als u impliciete herstel wilt uitschakelen, gebruikt u de --no-restore optie.

De dotnet restore opdracht is nog steeds nuttig in bepaalde scenario's waarbij het expliciet herstellen zinvol is, zoals builds voor continue integratie in Azure DevOps Services of in buildsystemen die expliciet moeten worden beheerd wanneer de herstelbewerking plaatsvindt.

Zie de dotnet restore documentatie voor informatie over het beheren van NuGet-feeds.

Deze opdracht ondersteunt de dotnet restore opties die worden doorgegeven in het lange formulier (bijvoorbeeld --source). Korte formulieropties, zoals -s, worden niet ondersteund.

Downloads van workloadmanifesten

Wanneer u deze opdracht uitvoert, wordt er een asynchrone achtergronddownload van reclamemanifesten voor workloads gestart. Als het downloaden nog steeds wordt uitgevoerd wanneer deze opdracht is voltooid, wordt het downloaden gestopt. Zie Reclamemanifesten voor meer informatie.

Argumenten

PROJECT | SOLUTION

Het project of de oplossing die moet worden verpakt. Het is een pad naar een csproj-, vbproj- of fsproj-bestand, of naar een oplossingsbestand of map. Als dit niet is opgegeven, zoekt de opdracht in de huidige map naar een project- of oplossingsbestand.

Opties

-c|--configuration <CONFIGURATION>

Definieert de buildconfiguratie. Als u ontwikkelt met de .NET 8 SDK of een latere versie, gebruikt de opdracht standaard de Release configuratie voor projecten waarvan TargetFramework is ingesteld net8.0 op of een latere versie. De standaard buildconfiguratie is Debug voor eerdere versies van de SDK en voor eerdere doelframeworks. U kunt de standaardinstelling in projectinstellingen overschrijven of door deze optie te gebruiken. Zie 'dotnet publish' maakt gebruik van releaseconfiguratie en dotnet pack maakt gebruik van releaseconfiguratie.

--force

Hiermee worden alle afhankelijkheden gedwongen om te worden opgelost, zelfs als de laatste herstelbewerking is geslaagd. Het opgeven van deze vlag is hetzelfde als het verwijderen van het project.assets.json bestand.

-?|-h|--help

Hiermee wordt een beschrijving afgedrukt van het gebruik van de opdracht.

--include-source

Bevat de foutopsporingssymbolen NuGet-pakketten naast de reguliere NuGet-pakketten in de uitvoermap. De bronbestanden zijn opgenomen in de src map in het symbolenpakket.
--include-symbols

Bevat de foutopsporingssymbolen NuGet-pakketten naast de reguliere NuGet-pakketten in de uitvoermap.

--interactive

Hiermee kan de opdracht stoppen en wachten op invoer of actie van de gebruiker. Bijvoorbeeld om de verificatie te voltooien. Beschikbaar sinds .NET Core 3.0 SDK.

--no-build

Het project wordt niet gebouwd voordat het wordt verpakt. De vlag wordt ook impliciet ingesteld --no-restore .
--no-dependencies

Negeert project-naar-projectverwijzingen en herstelt alleen het hoofdproject.
--no-restore

Voert geen impliciete herstelbewerking uit bij het uitvoeren van de opdracht.
--nologo

De opstartbanner of het copyrightbericht wordt niet weergegeven.
-o|--output <OUTPUT_DIRECTORY>

Hiermee plaatst u de ingebouwde pakketten in de opgegeven map.
- .NET 7.0.200 SDK
  
  Als u in de SDK 7.0.200 de optie opgeeft bij het --output uitvoeren van deze opdracht op een oplossing, wordt door de CLI een fout verzonden. Dit is een regressie en is opgelost in 7.0.201 en latere versies van de .NET SDK.
--runtime <RUNTIME_IDENTIFIER>

Hiermee geeft u de doelruntime op waarvoor pakketten moeten worden hersteld. Zie de RID-catalogus voor een lijst met runtime-id's (RID's).
-s|--serviceable

Hiermee stelt u de servicevlag in het pakket in. Zie .NET Blog: .NET Framework 4.5.1 Ondersteunt Microsoft-beveiligingsupdates voor .NET NuGet-bibliotheken voor meer informatie.

--tl:[auto|on|off]

Hiermee geeft u op of de terminallogger moet worden gebruikt voor de build-uitvoer. De standaardwaarde is auto, waarmee eerst de omgeving wordt geverifieerd voordat u terminallogboekregistratie inschakelt. De omgevingscontrole controleert of de terminal in staat is moderne uitvoerfuncties te gebruiken en geen omgeleide standaarduitvoer gebruikt voordat de nieuwe logger wordt ingeschakeld. on slaat de omgevingscontrole over en schakelt terminallogboekregistratie in. off slaat de omgevingscontrole over en maakt gebruik van de standaardconsolelogger.

De terminallogger toont u de herstelfase, gevolgd door de buildfase. Tijdens elke fase worden de huidige bouwprojecten onderaan de terminal weergegeven. Elk project dat wordt gebouwd, levert zowel het MSBuild-doel dat momenteel wordt gebouwd als de hoeveelheid tijd die aan dat doel is besteed. U kunt deze informatie doorzoeken voor meer informatie over de build. Wanneer een project klaar is met bouwen, wordt één sectie 'build completed' geschreven die het volgende vastlegt:
- De naam van het gebouwde project.
- Het doelframework (indien multi-targeted).
- De status van die build.
- De primaire uitvoer van die build (die is hyperlinked).
- Diagnostische gegevens die voor dat project worden gegenereerd.
Deze optie is beschikbaar vanaf .NET 8.

-v|--verbosity <LEVEL>

Hiermee stelt u het uitgebreidheidsniveau van de opdracht in. Toegestane waarden zijnq[uiet], , , n[ormal]en diag[nostic]d[etailed]m[inimal]. Zie LoggerVerbosity voor meer informatie.

--version-suffix <VERSION_SUFFIX>

Definieert de waarde voor de VersionSuffix eigenschap MSBuild. Het effect van deze eigenschap op de pakketversie is afhankelijk van de waarden van de Version en VersionPrefix eigenschappen, zoals wordt weergegeven in de volgende tabel:

Eigenschappen met waarden	Versie van het pakket
Geen	`1.0.0`
`Version`	`$(Version)`
`VersionPrefix` Alleen	`$(VersionPrefix)`
`VersionSuffix` Alleen	`1.0.0-$(VersionSuffix)`
`VersionPrefix` en `VersionSuffix`	`$(VersionPrefix)-$(VersionSuffix)`

Als u het projectbestand wilt gebruiken --version-suffix, geeft u VersionPrefix dit op en niet Version in het projectbestand. Als dat bijvoorbeeld VersionPrefix het is 0.1.2 en u doorgeeftdotnet pack--version-suffix rc.1, is 0.1.2-rc.1de pakketversie.

Als Version er een waarde is en u doorgeeft --version-suffixdotnet pack, wordt de opgegeven --version-suffix waarde genegeerd.

Voorbeelden

Pak het project in de huidige map in:
```
dotnet pack
```

Pak het app1 project in:

dotnet pack ~/projects/app1/project.csproj

Pak het project in de huidige map in en plaats de resulterende pakketten in de nupkgs map:
```
dotnet pack --output nupkgs
```
Pak het project in de huidige map in de nupkgs map en sla de buildstap over:
```
dotnet pack --no-build --output nupkgs
```
Als het versieachtervoegsel van het project is geconfigureerd zoals <VersionSuffix>$(VersionSuffix)</VersionSuffix> in het .csproj-bestand , moet u het huidige project inpakken en de resulterende pakketversie bijwerken met het opgegeven achtervoegsel:
```
dotnet pack --version-suffix "ci-1234"
```
Stel de pakketversie in op 2.1.0 met de PackageVersion eigenschap MSBuild:
```
dotnet pack -p:PackageVersion=2.1.0
```
Pak het project in voor een specifiek doelframework:
```
dotnet pack -p:TargetFrameworks=net45
```
Pak het project in en gebruik een specifieke runtime (Windows) voor de herstelbewerking:
```
dotnet pack --runtime win-x64
```
Pak het project in met behulp van een .nuspec-bestand :
```
dotnet pack ~/projects/app1/project.csproj -p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget
```
Zie de volgende bronnen voor meer informatie over het gebruik NuspecFile, NuspecBasePathen NuspecProperties: