dotnet pack

  • Статья

Эта статья относится к: ✔️ пакету SDK для .NET Core 3.1 и более поздних версий

Имя.

dotnet pack — упаковывает код в пакет NuGet.

Краткие сведения

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

Description

Команда dotnet pack выполняет сборку проекта и создает пакеты NuGet. Результат выполнения команды — пакет NuGet (то есть файл NUPKG).

Если вы хотите создать пакет, содержащий отладочные символы, доступны два варианта:

  • --include-symbols — создает пакет символов.
  • --include-source — создает пакет символов с папкой src, содержащей исходные файлы.

Зависимости NuGet упакованного проекта добавляются в файл NUSPEC, чтобы их можно было разрешить при установке пакета. Если упакованный проект содержит ссылки на другие проекты, другие проекты не включаются в пакет. Сейчас при наличии межпроектных зависимостей требуется один пакет на каждый проект.

dotnet pack по умолчанию сначала выполняет сборку проекта. Чтобы избежать этого, передайте параметр --no-build. Этот вариант часто бывает полезен, например в сценариях сборки с непрерывной интеграцией (CI), когда вы знаете, что код был собран недавно.

Примечание.

В некоторых случаях выполнить неявную сборку невозможно. Это может произойти, если задано свойство GeneratePackageOnBuild, позволяющее избежать циклической зависимости между целевыми объектами сборки и упаковки. Кроме того, сборка может завершиться ошибкой при наличии заблокированного файла или другой проблемы.

Может предоставлять свойства MSBuild команде dotnet pack для процесса упаковки. Дополнительные сведения см. в разделах Свойства целевого объекта пакета NuGet и Справочник по командной строке MSBuild. В разделе Примеры показано, как использовать параметр -p MSBuild в различных сценариях.

Примечание.

Веб-проекты не упаковываются.

Неявное восстановление

Вам не нужно выполнять команду dotnet restore, так как она выполняется неявно всеми командами, которые требуют восстановления, например dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish и dotnet pack. Чтобы отключить неявное восстановление, используйте параметр --no-restore.

Команду dotnet restore по-прежнему удобно использовать в некоторых сценариях, где необходимо явное восстановление, например в сборках с использованием непрерывной интеграции в Azure DevOps Services или системах сборки, где требуется явно контролировать время восстановления.

Сведения об управлении веб-каналами NuGet см. в документации по dotnet restore.

Эта команда поддерживает параметры dotnet restore при передаче в длинной форме (например, --source). Параметры в краткой форме, например -s, не поддерживаются.

Скачивание манифестов рабочих нагрузок

При выполнении этой команды запускается асинхронное фоновое скачивание оповестительных манифестов для рабочих нагрузок. Если скачивание по-прежнему выполняется по завершении этой команды, оно останавливается. Дополнительные сведения см. в разделе Оповестительные манифесты.

Аргументы

PROJECT | SOLUTION

Проект или решение для упаковки. Это путь к файлу CSPROJ, VBPROJ или FSPROJ, либо к файлу решения или каталогу. Если он не указан, команда ищет текущий каталог для файла решения или проекта.

Параметры

  • -c|--configuration <CONFIGURATION>

    Определяет конфигурацию сборки. Если вы разрабатываете пакет SDK для .NET 8 или более позднюю версию, команда использует Release конфигурацию по умолчанию для проектов, для которых targetFramework имеет net8.0 или более позднюю версию. Конфигурация сборки по умолчанию используется Debug для более ранних версий пакета SDK и для более ранних целевых платформ. Вы можете переопределить значение по умолчанию в параметрах проекта или с помощью этого параметра. Дополнительные сведения см. в разделе "Dotnet publish" использует конфигурацию выпуска и "dotnet pack" использует конфигурацию выпуска.

  • --force

    Принудительное разрешение всех зависимостей, даже если последнее восстановление прошло успешно. Указание этого флага дает тот же результат, что удаление файла project.assets.json.

  • -?|-h|--help

    Выводит описание использования команды.

  • --include-source

    Включает пакеты NuGet отладочных символов в дополнение к обычным пакетам NuGet в выходном каталоге. Исходные файлы включены в папку src пакета символов.

  • --include-symbols

    Включает пакеты NuGet отладочных символов в дополнение к обычным пакетам NuGet в выходном каталоге.

  • --interactive

    Позволяет команде остановиться и дождаться, пока пользователь выполнит действие или введет данные. Например, чтобы завершить проверку подлинности. Доступно, начиная с пакета SDK для .NET Core 3.0.

  • --no-build

    Не выполняет сборку проекта перед упаковкой. Он также неявно задает флаг --no-restore.

  • --no-dependencies

    Межпроектные ссылки игнорируются, и восстанавливается только корневой проект.

  • --no-restore

    Не выполняет неявное восстановление при выполнении команды.

  • --nologo

    Скрывает загрузочный баннер или сообщение об авторских правах.

  • -o|--output <OUTPUT_DIRECTORY>

    Собранные пакеты помещаются в указанный каталог.

    • Пакет SDK для .NET 7.0.200

      В пакете SDK 7.0.200, если вы укажете --output параметр при выполнении этой команды в решении, интерфейс командной строки выдает ошибку. Это регрессия и исправлена в версии 7.0.201 и более поздних версий пакета SDK для .NET.

  • --runtime <RUNTIME_IDENTIFIER>

    Задает целевую среду выполнения для восстановления пакетов. Список идентификаторов сред выполнения (RID) см. в каталоге RID.

  • -s|--serviceable

    Задает флаг "подлежит обслуживанию" в пакете. Дополнительные сведения см. в записи блога о том, что .NET Framework 4.5.1 поддерживает обновления системы безопасности Майкрософт для библиотек .NET NuGet.

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

    Указывает, следует ли использовать средство ведения журнала терминала для выходных данных сборки. Значением по умолчанию является autoто, что сначала проверяет среду перед включением ведения журнала терминалов. Среда проверка проверяет, может ли терминал использовать современные выходные функции и не использует перенаправленные стандартные выходные данные перед включением нового средства ведения журнала. onпропускает проверка среды и включает ведение журнала терминалов. offпропускает среду проверка и использует средство ведения журнала консоли по умолчанию.

    Средство ведения журнала терминала показывает этап восстановления, за которым следует этап сборки. На каждом этапе в нижней части терминала отображаются строительные проекты. Каждый проект, который создает выходные данные как целевого объекта MSBuild, который в настоящее время создается, так и время, затраченное на этот целевой объект. Эти сведения можно найти, чтобы узнать больше о сборке. После завершения сборки проекта записывается один раздел "сборка завершена", который записывает:

    • Имя созданного проекта.
    • Целевая платформа (если она используется с несколькими целевыми объектами).
    • Состояние этой сборки.
    • Основные выходные данные этой сборки (которая гиперссылок).
    • Все диагностика, созданные для этого проекта.

    Этот параметр доступен начиная с .NET 8.

  • -v|--verbosity <LEVEL>

    Задает уровень детализации команды. Допустимые значения: q[uiet], m[inimal], n[ormal], d[etailed] и diag[nostic]. Дополнительные сведения см. в разделе LoggerVerbosity.

  • --version-suffix <VERSION_SUFFIX>

    Определяет значение для свойства VersionSuffix MSBuild. Воздействие этого свойства на версию пакета зависит от значений свойств Version и VersionPrefix, как показано в следующей таблице:

    Свойства со значениями Версия пакета
    нет 1.0.0
    Version $(Version)
    Только VersionPrefix $(VersionPrefix)
    Только VersionSuffix 1.0.0-$(VersionSuffix)
    VersionPrefix и VersionSuffix. $(VersionPrefix)-$(VersionSuffix)

    Если вы хотите использовать --version-suffix, укажите VersionPrefix, а не Version, в файле проекта. Например, если параметр VersionPrefix имеет значение 0.1.2, а вы передаете --version-suffix rc.1 в dotnet pack, версия пакета будет иметь значение 0.1.2-rc.1.

    Если Version имеет значение, а вы передаете --version-suffix в dotnet pack, то значение, указанное для --version-suffix, игнорируется.

Примеры

  • Упаковка проекта в текущем каталоге:

    dotnet pack

  • Упаковка проекта app1:

    dotnet pack ~/projects/app1/project.csproj

  • Упаковка проекта в текущем каталоге; полученные пакеты помещаются в папку nupkgs:

    dotnet pack --output nupkgs

  • Упаковка проекта в текущем каталоге в папку nupkgs и пропуск этапа сборки:

    dotnet pack --no-build --output nupkgs

  • Если суффикс версии пакета в файле CSPROJ настроен как <VersionSuffix>$(VersionSuffix)</VersionSuffix>, упаковка текущего проекта и обновление версии полученных пакетов с использованием указанного суффикса:

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

  • Устанавливает версию пакета в 2.1.0 с использованием свойства MSBuild PackageVersion:

    dotnet pack -p:PackageVersion=2.1.0

  • Упакуйте проект для требуемой версии .NET Framework:

    dotnet pack -p:TargetFrameworks=net45

  • Упаковайте проект и используйте определенную среду выполнения (Windows) для операции восстановления:

    dotnet pack --runtime win-x64

  • Упакуйте проект с помощью NUSPEC-файла:

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

    Дополнительные сведения об использовании NuspecFile, NuspecBasePath и NuspecProperties см. в следующих документах: