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>] [--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
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ącymsrc
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 run
dotnet 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
--artifacts-path <ARTIFACTS_DIR>
Wszystkie pliki wyjściowe kompilacji z wykonanego polecenia zostaną umieszczone w podfolderach w określonej ścieżce oddzielonej przez projekt. Aby uzyskać więcej informacji, zobacz Artifacts Output Layout (Układ danych wyjściowych artefaktów). Dostępne od zestawu .NET 8 SDK.
-c|--configuration <CONFIGURATION>
Definiuje konfigurację kompilacji. Jeśli programujesz przy użyciu zestawu .NET 8 SDK lub nowszej wersji, polecenie domyślnie używa
Release
konfiguracji dla projektów, których element TargetFramework jest ustawiony nanet8.0
lub nowszą wersję. Domyślna konfiguracja kompilacji dotyczyDebug
wcześniejszych wersji zestawu SDK i wcześniejszych platform docelowych. Wartość domyślną można zastąpić w ustawieniach projektu lub za pomocą tej opcji. Aby uzyskać więcej informacji, zobacz "dotnet publish" używa konfiguracji wydania i "dotnet pack" używa konfiguracji wydania.
--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]
, idiag[nostic]
. Aby uzyskać więcej informacji, zobacz 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ściVersion
właściwości iVersionPrefix
, 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
Tylko1.0.0-$(VersionSuffix)
VersionPrefix
iVersionSuffix
$(VersionPrefix)-$(VersionSuffix)
Jeśli chcesz użyć polecenia
--version-suffix
, określVersionPrefix
plik projektu, a nieVersion
w pliku projektu. Na przykład jeśliVersionPrefix
element ma0.1.2
wartość i zostanie przekazana--version-suffix rc.1
dodotnet pack
elementu , wersja pakietu będzie mieć wartość0.1.2-rc.1
.Jeśli
Version
ma wartość i przekazujesz--version-suffix
dodotnet pack
elementu , 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) dla operacji przywracania:
dotnet pack --runtime win-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
NuspecFile
elementów ,NuspecBasePath
iNuspecProperties
, zobacz następujące zasoby: