Поделиться через

dotnet publish

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

Имя

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

Синопсис

dotnet publish [<PROJECT>|<SOLUTION>|<FILE>] [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-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] [--no-self-contained]
    [-s|--source <SOURCE>] [--tl:[auto|on|off]]
    [--ucr|--use-current-runtime]
    [-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.

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

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

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

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

MSBuild

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

Все параметры, передаваемые в dotnet publish, передаются в MSBuild. Параметры -c и -o сопоставляют Configuration MSBuild и 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

    Упаковыв приложение в отдельный исполняемый файл платформы. Дополнительные сведения о публикации с одним файлом см. в документе конструктора пакета с одним файлом. Если для этого свойства задано trueзначение , PublishSelfContained свойство неявно задано true.

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

  • PublishTrimmed

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

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

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

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

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

Аргументы

PROJECT | SOLUTION | FILE

Файл проекта или решения или C# (файлового приложения) для работы. Если файл не указан, MSBuild ищет текущий каталог для проекта или решения.

  • PROJECT — это путь и имя файла файла проекта C#, F# или Visual Basic, или путь к каталогу, который содержит файл проекта C#, F# или Visual Basic.

  • SOLUTION — это путь и имя файла решения (.sln или расширение SLNX) или путь к каталогу, содержаму файл решения.

  • FILE — это аргумент, добавленный в .NET 10. Путь и имя файла приложения на основе файлов. Приложения на основе файлов содержатся в одном файле, который создается и запускается без соответствующего файла проекта (CSPROJ). Дополнительные сведения см. в разделе "Создание файловых приложений C#".

Параметры

  • -a|--arch <ARCHITECTURE>

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

  • --artifacts-path <ARTIFACTS_DIR>

    Все выходные файлы сборки из выполняемой команды будут отправляться в вложенные папки в соответствии с указанным путем, разделенным проектом. Дополнительные сведения см. в макете выходных данных артефактов. Доступно с пакета SDK для .NET 8.

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

  • --interactive

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

  • --manifest <PATH_TO_MANIFEST_FILE>

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

  • --no-build

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

  • --no-dependencies

    Игнорирует ссылки на проекты и восстанавливает только корневой проект.

  • --nologo

    Не отображает баннер запуска или сообщение об авторских правах.

  • --no-restore

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

  • -o|--output <OUTPUT_DIRECTORY>

    Указывает путь к выходному каталогу.

    Если он не указан, по умолчанию используется значение [project_file_folder]/bin/[configuration]/[framework]/publish/ для исполняемых файлов, зависящих от платформы, и межплатформенных двоичных файлов. По умолчанию [project_file_folder]/bin/[configuration]/[framework]/[runtime]/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 и более поздних версий

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

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

  • --os <OS>

    Указывает целевую операционную систему (ОС). Это краткий синтаксис для заданияидентификатора среды выполнения (RID), где предоставленное значение сочетается с параметром RID по умолчанию. Например, на win-x64 компьютере, указывая, --os linux задает параметр RID для linux-x64. Если этот параметр используется, не используйте параметр -r|--runtime. Доступно с .NET 6.

  • --sc|--self-contained

    Опубликуйте среду выполнения .NET в приложении, чтобы среда выполнения не должна быть установлена на целевом компьютере. Значение по умолчанию — true.

  • --no-self-contained

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

  • --source <SOURCE>

    Универсальный код ресурса (URI) источника пакета NuGet для использования во время операции восстановления.

  • -r|--runtime <RUNTIME_IDENTIFIER>

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

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

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

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

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

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

  • --ucr|--use-current-runtime

    Используйте текущую среду выполнения в качестве целевой среды выполнения.

  • -v|--verbosity <LEVEL>

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

  • --version-suffix <VERSION_SUFFIX>

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

  • -?|-h|--help

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

Примеры

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

    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 net8.0 --runtime osx-x64

  • Опубликуйте указанный файл проекта:

    dotnet publish ~/projects/app1/app1.csproj

  • Опубликуйте текущее приложение, но не восстанавливайте ссылки на project-to-project (P2P) только корневой проект во время операции восстановления:

    dotnet publish --no-dependencies

  • Опубликуйте файловую программу C# app.cs в текущем каталоге:

    dotnet publish app.cs

    Поддержка файловой программы добавлена в пакет SDK для .NET 10.0.100.

См. также

  • Last updated on