dotnet publish

  • Статья

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

Имя.

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

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

dotnet publish [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
    [-c|--configuration <CONFIGURATION>] [--disable-build-servers]
    [-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>]
    [--sc|--self-contained [true|false]] [--no-self-contained]
    [-s|--source <SOURCE>] [--tl:[auto|on|off]]
    [--use-current-runtime, --ucr [true|false]]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet publish -h|--help

Description

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-файлы

Вы также можете задать свойства, связанные с публикацией, ссылаясь на PUBXML-файл . Например:

dotnet publish -p:PublishProfile=FolderProfile

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

В PUBXML-файле:

  • PublishUrl используется Visual Studio для обозначения целевого объекта публикации.
  • PublishDir используется интерфейсом командной строки для обозначения целевого объекта публикации.

Если вы хотите, чтобы сценарий работал во всех местах, можно инициализировать оба этих свойства в одном и том же значении в PUBXML-файле . При разрешении проблемы GitHub dotnet/sdk#20931 необходимо задать только одно из этих свойств.

Некоторые свойства в PUBXML-файле учитываются только Visual Studio и не влияют на dotnet publishних. Мы работаем над тем, чтобы сделать интерфейс командной строки более в соответствии с поведением Visual Studio. Но некоторые свойства никогда не будут использоваться интерфейсом командной строки. Интерфейс командной строки и Visual Studio выполняют аспекты публикации и dotnet/sdk#29817 , чтобы добавить поддержку дополнительных свойств, связанных с этим. Но интерфейс командной строки не выполняет аспект автоматизации развертывания публикации, а свойства, связанные с ними, не поддерживаются. Наиболее заметные свойства PUBXML , которые не поддерживаются dotnet publish , являются следующими, которые влияют на сборку:

  • LastUsedBuildConfiguration
  • Configuration
  • Platform
  • LastUsedPlatform
  • TargetFramework
  • TargetFrameworks
  • RuntimeIdentifier
  • RuntimeIdentifiers

свойства MSBuild

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

  • PublishReadyToRun

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

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

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

  • PublishSingleFile

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

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

  • PublishTrimmed

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

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

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

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

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

Аргументы

  • PROJECT|SOLUTION

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

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

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

Параметры

  • -a|--arch <ARCHITECTURE>

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

  • -c|--configuration <CONFIGURATION>

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

  • --disable-build-servers

    Принудительно заставляет команду игнорировать все постоянные серверы сборки. Этот параметр предоставляет согласованный способ отключить все использование кэширования сборки, которая заставляет сборку с нуля. Сборка, которая не зависит от кэшей, полезна, когда кэши могут быть повреждены или неверны по какой-то причине. Доступно с пакета SDK для .NET 7.

  • -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

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

  • --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 7.0.200 и более поздних версий

      Если указать --output параметр при выполнении этой команды в решении, интерфейс командной строки выдает предупреждение (ошибка в версии 7.0.200) из-за неясной семантики выходного пути. Этот --output параметр запрещен, так как все выходные данные всех встроенных проектов будут скопированы в указанный каталог, который не совместим с многоцелыми проектами, а также проектами с различными версиями прямых и транзитивных зависимостей. Дополнительные сведения см. в разделе "Параметр уровня --output решения" больше недействителен для команд, связанных со сборкой.

    • Пакет 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 linux, идентификатору RID присваивается значение linux-x64. При использовании этого параметра не используйте параметр -r|--runtime. Доступно с .NET 6.

  • --sc|--self-contained [true|false]

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

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

  • --no-self-contained

    Эквивалент --self-contained false.

  • --source <SOURCE>

    URI источника пакета NuGet для использования во время операции восстановления.

  • -r|--runtime <RUNTIME_IDENTIFIER>

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

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

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

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

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

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

  • --use-current-runtime, --ucr [true|false]

    RuntimeIdentifier Задает переносимую RuntimeIdentifier платформу на основе одного из компьютеров. Это происходит неявно с свойствами, которые требуютRuntimeIdentifier, например SelfContained, , PublishAotPublishSelfContained, PublishSingleFileи PublishReadyToRun. Если для свойства задано значение false, это неявное разрешение больше не будет происходить.

  • -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-x64

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

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

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

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

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

    dotnet publish --framework netcoreapp3.1 --runtime osx-x64

  • Публикация указанного файла проекта:

    dotnet publish ~/projects/app1/app1.csproj

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

    dotnet publish --no-dependencies

См. также