dotnet publish

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

name

dotnet publish — публикует приложение и его зависимости в папке для развертывания на размещающей системе.

Краткий обзор

dotnet publish [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>] [--force] [--interactive]
    [--manifest <PATH_TO_MANIFEST_FILE>] [--no-build] [--no-dependencies]
    [--no-restore] [--nologo] [-o|--output <OUTPUT_DIRECTORY>]
    [--os <OS>] [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--self-contained [true|false]]
    [--no-self-contained] [-v|--verbosity <LEVEL>]
    [--version-suffix <VERSION_SUFFIX>]

dotnet publish -h|--help

Описание

dotnet publish компилирует приложение, считывает его зависимости, указанные в файле проекта, и публикует итоговый набор файлов в каталоге. Выходные данные включают следующие ресурсы:

  • Код на промежуточном языке (IL) в сборке с расширением DLL.
  • Файл .deps.json, содержащий все зависимости проекта.
  • Файл .runtimeconfig.json, определяющий общую среду выполнения, которую ожидает приложение, а также другие параметры конфигурации для среды выполнения (например, тип сборки мусора).
  • Зависимости приложения, которые копируются из кэша NuGet в выходную папку.

Выходные данные команды dotnet publish готовы к развертыванию в размещающей системе (например, на сервере, ПК, Mac, ноутбуке) для выполнения. Это единственный официальный способ подготовить приложение к развертыванию. В зависимости от указанного в проекте типа развертывания размещающая система может как иметь, так и не иметь общую среду выполнения .NET. Дополнительные сведения см. в статье Публикация приложений .NET с помощью .NET CLI.

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

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

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

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

MSBuild

Команда dotnet publish вызывает метод MSBuild, который, в свою очередь, вызывает целевой объект Publish. Если для свойства IsPublishable задано значение false в конкретном проекте, целевой объект Publish не может быть вызван, а команда dotnet publish запускает в проекте только неявную команду dotnet restore.

Все параметры, передаваемые в dotnet publish, передаются далее в MSBuild. Параметры -c и -o сопоставляются со свойствами MSBuild Configuration и PublishDir соответственно.

Команда dotnet publish принимает параметры MSBuild, например -p для задания свойств или -l для определения средства ведения журнала. Например, можно задать свойство MSBuild, используя формат: -p:<NAME>=<VALUE>.

Кроме того, задать связанные с публикацией свойства можно, сославшись на файл PUBXML (появившийся в пакете SDK для .NET Core 3.1). Например:

dotnet publish -p:PublishProfile=FolderProfile

В предыдущем примере используется файл FolderProfile.pubxml, расположенный в папке <project_folder>/Properties/PublishProfiles. Если указать путь и расширение файла при определении свойства PublishProfile, эти сведения будут игнорироваться. По умолчанию MSBuild выполняет поиск в папке Properties/PublishProfiles по расширению файла pubxml. Чтобы указать путь и имя файла, включая расширение, определите свойство PublishProfileFullPath вместо свойства PublishProfile.

Следующие свойства MSBuild изменяют выходные данные dotnet publish.

  • PublishReadyToRun

    Компилирует сборки приложений в формате ReadyToRun (R2R). R2R является разновидностью компиляции AOT. Дополнительные сведения см. в разделе Образы ReadyToRun. Доступно, начиная с пакета SDK для .NET Core 3.0.

    Чтобы просмотреть предупреждения о недостающих зависимостях, из-за которых могут возникать сбои в среде выполнения, используйте PublishReadyToRunShowWarnings=true.

    Параметр PublishReadyToRun рекомендуется указывать в профиле публикации, а не в командной строке.

  • PublishSingleFile

    Упаковывает приложение в однофайловый исполняемый файл для конкретной платформы. Дополнительные сведения о публикации однофайловых исполняемых файлов см. в документе о разработке однофайловых пакетных установщиков. Доступно, начиная с пакета SDK для .NET Core 3.0.

    Рекомендуется указывать этот параметр в файле проекта, а не в командной строке.

  • PublishTrimmed

    Обрезает неиспользуемые библиотеки, чтобы уменьшить размер развертывания приложения при публикации автономного исполняемого файла. Дополнительные сведения см. в статье Обрезка автономных развертываний и исполняемых файлов. Доступно начиная с пакета SDK для .NET 6.

    Рекомендуется указывать этот параметр в файле проекта, а не в командной строке.

Дополнительные сведения см. в следующих ресурсах:

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

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

Аргументы

  • PROJECT|SOLUTION

    Проект или решение для публикации.

    • PROJECT — это путь или имя файла проекта C#, F# или Visual Basic либо путь к папке, которая содержит файл проекта C#, F# или Visual Basic. Если каталог не указан, по умолчанию используется текущий каталог.

    • SOLUTION — это путь и имя для файла решения (расширение SLN) или путь к каталогу, содержащему файл решения. Если каталог не указан, по умолчанию используется текущий каталог. Доступно, начиная с пакета SDK для .NET Core 3.0.

Параметры

  • -a|--arch <ARCHITECTURE>

    Указывает целевую архитектуру. Это сокращенный синтаксис для настройки идентификатора среды выполнения (RID), где указанное значение объединяется с RID по умолчанию. Например, если на компьютере win-x64 указать --arch x86, идентификатору RID присваивается значение win-x86. При использовании этого параметра не используйте параметр -r|--runtime. Этот параметр доступен с выпуска .NET 6, предварительная версия 7.

  • -c|--configuration <CONFIGURATION>

    Определяет конфигурацию сборки. По умолчанию для большинства проектов используется Debug, но можно переопределить параметры конфигурации сборки в проекте.

  • -f|--framework <FRAMEWORK>

    Публикует приложение для указанной целевой платформы. Вам нужно указать целевую платформу в файле проекта.

  • --force

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

  • -?|-h|--help

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

  • --interactive

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

  • --manifest <PATH_TO_MANIFEST_FILE>

    Определяет один или несколько целевых манифестов для усечения множества пакетов, публикуемых вместе с приложением. Файл манифеста является частью выходных данных команды dotnet store. Чтобы указать несколько манифестов, добавьте параметр --manifest для каждого из них.

  • --no-build

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

  • --no-dependencies

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

  • --nologo

    Скрывает загрузочный баннер или сообщение об авторских правах. Доступно, начиная с пакета SDK для .NET Core 3.0.

  • --no-restore

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

  • -o|--output <OUTPUT_DIRECTORY>

    Задает путь для выходного каталога.

    Если значение не указано, для исполняемого файла, зависящего от платформы, а также для кроссплатформенных двоичных файлов по умолчанию используется путь [папка_файла_проекта]/bin/[конфигурация]/[платформа]/publish/ . Для автономного исполняемого файла по умолчанию используется путь [папка_файла_проекта]/bin/[конфигурация]/[платформа]/[среда выполения]/publish/ .

    Если в веб-проекте выходная папка находится в папке проекта, последовательное выполнение команд dotnet publish приводит к созданию вложенных выходных папок. Например, если папкой проекта является MyProject, папкой выходных данных публикации — myproject/publish и вы дважды запускаете dotnet publish, при втором запуске файлы содержимого, такие как .config и .json помещаются в папку myproject/publish/publish. Чтобы избежать вложенности папок публикации, укажите папку публикации, которая не находится непосредственно в папке проекта, или исключите папку публикации из проекта. Чтобы исключить папку публикации с именем publishoutput, добавьте следующий элемент в элемент PropertyGroup в файле .csproj.

    <DefaultItemExcludes>$(DefaultItemExcludes);publishoutput**</DefaultItemExcludes>
    
    • Пакет SDK для .NET Core 3.x и более поздних версий

      Если относительный путь указывается при публикации проекта, созданный выходной каталог задается относительно текущего рабочего каталога, а не расположения файла проекта.

      Если относительный путь указывается при публикации решения, все выходные данные для всех проектов помещаются в указанную папку относительно текущего рабочего каталога. Для размещения выходных данных публикации в отдельные папки для каждого проекта укажите относительный путь, используя свойство PublishDir msbuild вместо параметра --output. Например, dotnet publish -p:PublishDir=.\publish отправляет выходные данные публикации для каждого проекта в папку publish, находящуюся в папке с файлом проекта.

    • Пакет SDK для .NET Core 2.x

      Если относительный путь указывается при публикации проекта, созданный выходной каталог задается относительно расположения файла проекта, а не текущего рабочего каталога.

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

  • --os <OS>

    Позволяет указать целевую операционную систему. Это сокращенный синтаксис для настройки идентификатора среды выполнения (RID), где указанное значение объединяется с RID по умолчанию. Например, если на компьютере win-x64 указать --os os, идентификатору RID присваивается значение os-x64. При использовании этого параметра не используйте параметр -r|--runtime. Этот параметр доступен начиная с выпуска .NET 6 предварительной версии 7.

  • --self-contained [true|false]

    Публикует среду выполнения .NET вместе с приложением, что позволяет не устанавливать ее на конечном компьютере. Значение по умолчанию — true, если указан идентификатор среды выполнения и проект является исполняемым проектом (а не проектом библиотеки). Дополнительные сведения см. в разделах Публикация приложения .NET и Публикация приложений .NET с помощью .NET CLI.

    Если этот параметр используется без указания true или false, по умолчанию применяется true. В этом случае не помещайте аргумент решения или проекта сразу после --self-contained, поскольку здесь ожидается true или false.

  • --no-self-contained

    Эквивалент --self-contained false. Доступно, начиная с пакета SDK для .NET Core 3.0.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Публикует приложение для данной среды выполнения. Список идентификаторов сред выполнения (RID) см. в каталоге RID. Дополнительные сведения см. в разделах Публикация приложения .NET и Публикация приложений .NET с помощью .NET CLI. При использовании этого параметра используйте также --self-contained или --no-self-contained.

  • -v|--verbosity <LEVEL>

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

  • --version-suffix <VERSION_SUFFIX>

    Определяет суффикс версии для замены звездочки (*) в поле версия файла проекта.

Примеры

  • Создание кроссплатформенного двоичного файла, зависящего от платформы, для проекта в текущем каталоге:

    dotnet publish
    

    Начиная с пакета SDK для .NET Core 3.0 этот пример также создает зависящий от платформы исполняемый файл для текущей платформы.

  • Создание автономного исполняемого файла для проекта в текущем каталоге для конкретной среды выполнения:

    dotnet publish --runtime osx.10.11-x64
    

    Идентификатор RID должен находиться в файле проекта.

  • Создание зависящего от платформы исполняемого файла для проекта в текущем каталоге для конкретной платформы:

    dotnet publish --runtime osx.10.11-x64 --self-contained false
    

    Идентификатор RID должен находиться в файле проекта. Этот пример относится к пакету SDK для .NET Core 3.0 и более поздних версий.

  • Публикация проекта в текущем каталоге для конкретной среды выполнения и целевой платформы:

    dotnet publish --framework netcoreapp3.1 --runtime osx.10.11-x64
    
  • Публикация указанного файла проекта:

    dotnet publish ~/projects/app1/app1.csproj
    
  • Публикация текущего приложения с обработкой только корневого проекта, без восстановления ссылок между проектами (P2P), во время операции восстановления:

    dotnet publish --no-dependencies
    

См. также