dotnet publish

  • Artículo

Este artículo se aplica a: ✔️ SDK de .NET Core 3.1 y versiones posteriores

NOMBRE

dotnet publish: publica la aplicación y sus dependencias en una carpeta para la implementación en un sistema de hospedaje.

Sinopsis

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

Descripción

dotnet publish: compila la aplicación, lee sus dependencias especificadas en el archivo de proyecto y publica el conjunto resultante de archivos en un directorio. La salida incluye los recursos siguientes:

  • Código de lenguaje intermedio (IL) en un ensamblado con una extensión dll.
  • Un archivo .deps.json que incluye todas las dependencias del proyecto.
  • Un archivo .runtime.config.json en el que se especifica el tiempo de ejecución compartido que espera la aplicación, así como otras opciones de configuración para el tiempo de ejecución (por ejemplo, el tipo de recolección de elementos no utilizados).
  • Las dependencias de la aplicación, que se copian de la caché de NuGet a la carpeta de salida.

La salida del comando dotnet publish está lista para la implementación en un sistema de hospedaje (por ejemplo, un servidor, un equipo PC o Mac, un portátil) para la ejecución. Es la única manera admitida oficialmente para preparar la aplicación para la implementación. En función del tipo de implementación que especifique el proyecto, el sistema de hospedaje puede o no tener instalado el entorno de ejecución compartido de .NET. Para obtener más información, vea Publicación de aplicaciones de .NET con la CLI de .NET.

Restauración implícita

No es necesario ejecutar dotnet restore porque lo ejecutan implícitamente todos los comandos que necesitan que se produzca una restauración, como dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish y dotnet pack. Para deshabilitar la restauración implícita, use la opción --no-restore.

El comando dotnet restore sigue siendo válido en algunos escenarios donde tiene sentido realizar una restauración explícita, como las compilaciones de integración continua en Azure DevOps Services o en los sistemas de compilación que necesitan controlar explícitamente cuándo se produce la restauración.

Para obtener información sobre cómo administrar fuentes de NuGet, vea la documentación de dotnet restore.

MSBuild

Con el comando dotnet publish se llama a MSBuild, lo que invoca el destino Publish. Si la propiedad IsPublishable se establece en false para un proyecto determinado, no se puede invocar el destino Publish y el comando dotnet publish solo ejecuta el comando dotnet restore implícito en el proyecto.

Todos los parámetros pasados a dotnet publish se pasan a MSBuild. Los parámetros -c y -o se asignan respectivamente a las propiedades Configuration y PublishDir de MSBuild.

El comando dotnet publish acepta opciones de MSBuild, como -p para establecer propiedades y -l para definir un registrador. Por ejemplo, se puede establecer una propiedad de MSBuild mediante el uso del formato: -p:<NAME>=<VALUE>.

Archivos .pubxml

También se pueden establecer las propiedades relacionadas con la publicación si se hace referencia a un archivo .pubxml. Por ejemplo:

dotnet publish -p:PublishProfile=FolderProfile

En el ejemplo anterior se usa el archivo FolderProfile.pubxml, que se encuentra en la carpeta <project_folder>/Properties/PublishProfiles. Si especifica una ruta de acceso y una extensión de archivo al establecer la propiedad PublishProfile, estas se omiten. De forma predeterminada, MSBuild busca en la carpeta Properties/PublishProfiles y da por hecho la extensión de archivo pubxml. Para especificar la ruta de acceso y el nombre de archivo, incluida la extensión, establezca la propiedad PublishProfileFullPath en lugar de la propiedad PublishProfile.

En el archivo .pubxml:

  • Visual Studio utiliza PublishUrl para indicar el destino de publicación.
  • La CLI utiliza PublishDir para indicar el destino de publicación.

Si desea que el escenario funcione en todos los lugares, puede inicializar las dos propiedades con el mismo valor en el archivo .pubxml. Cuando se resuelva el problema de GitHub dotnet/sdk#20931, solo será necesario establecer una de estas propiedades.

Visual Studio solo respeta algunas propiedades del archivo .pubxml, que no tienen ningún efecto en dotnet publish. Estamos trabajando para que la CLI esté más alineada con el comportamiento de Visual Studio. Sin embargo, la CLI nunca usará algunas propiedades. Tanto la CLI como Visual Studio se encargan del aspecto de empaquetado de la publicación, y dotnet/sdk#29817 planea agregar compatibilidad con más propiedades relacionadas con eso. Pero la CLI no se ocupa del aspecto de automatización de la implementación de la publicación y las propiedades relacionadas que no se admiten. Las propiedades .pubxml más notables que no son compatibles con dotnet publish son las siguientes, que afectan a la compilación:

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

propiedades de MSBuild

Las propiedades de MSBuild siguientes cambian la salida de dotnet publish.

  • PublishReadyToRun

    Compila los ensamblados de aplicación con el formato ReadyToRun (R2R). R2R es una forma de compilación Ahead Of Time (AOT). Para obtener más información, vea Imágenes ReadyToRun.

    Para ver las advertencias sobre las dependencias que faltan y que podrían provocar errores del entorno de ejecución, use PublishReadyToRunShowWarnings=true.

    Se recomienda especificar PublishReadyToRun en un perfil de publicación en lugar de hacerlo en la línea de comandos.

  • PublishSingleFile

    Empaqueta la aplicación en un ejecutable de archivo único específico de la plataforma. Para obtener más información sobre la publicación de archivos únicos, vea el documento de diseño del programa de instalación de conjunto de archivos únicos.

    Se recomienda especificar esta opción en el archivo del proyecto en lugar de hacerlo en la línea de comandos.

  • PublishTrimmed

    Recorta las bibliotecas no utilizadas para reducir el tamaño de implementación de una aplicación cuando se publica un ejecutable independiente. Para obtener más información, vea Recorte de implementaciones autocontenidas y ejecutables. Disponible a partir del SDK de .NET 6.

    Se recomienda especificar esta opción en el archivo del proyecto en lugar de hacerlo en la línea de comandos.

Para obtener más información, vea los siguientes recursos:

Descargas de manifiestos de cargas de trabajo

Cuando se ejecuta, este comando inicia una descarga asincrónica en segundo plano de manifiestos de publicidad de cargas de trabajo. Si la descarga no ha terminado cuando finaliza el comando, se detiene. Para obtener más información, vea Manifiestos de publicidad.

Argumentos

  • PROJECT|SOLUTION

    El archivo de proyecto o solución que se va a publicar.

    • PROJECT es la ruta y el nombre de un archivo de proyecto de C#, F# o Visual Basic, o bien la ruta a un directorio que contiene un archivo de proyecto de C#, F# o Visual Basic. Si no se especifica el directorio, se toma como predeterminado el actual.

    • SOLUTION es la ruta de acceso y el nombre de archivo de un archivo de solución (extensión .sln), o bien la ruta de acceso a un directorio que contiene un archivo de solución. Si no se especifica el directorio, se toma como predeterminado el actual.

Opciones

  • -a|--arch <ARCHITECTURE>

    Especifica la arquitectura de destino. Se trata de una sintaxis abreviada para establecer el identificador del entorno de ejecución (RID), donde el valor proporcionado se combina con el RID predeterminado. Por ejemplo, en un equipo win-x64, al especificar --arch x86 se establece el RID en win-x86. Si usa esta opción, no use la opción -r|--runtime. Disponible a partir de .NET 6 (versión preliminar 7).

  • -c|--configuration <CONFIGURATION>

    Define la configuración de compilación. Si está desarrollando con el SDK de .NET 8 o una versión posterior, el comando usa la Release configuración de forma predeterminada para los proyectos cuyo TargetFramework está establecido net8.0 en o una versión posterior. La configuración de compilación predeterminada es Debug para versiones anteriores del SDK y para marcos de destino anteriores. Puede invalidar el valor predeterminado en la configuración del proyecto o mediante esta opción. Para obtener más información, vea "dotnet publish" usa la configuración de versión y "dotnet pack" usa la configuración de versión.

  • --disable-build-servers

    Obliga al comando a omitir los servidores de compilación persistentes. Esta opción proporciona una manera coherente de deshabilitar todo el uso del almacenamiento en caché de compilación, lo que fuerza una compilación desde cero. Una compilación que no se basa en memorias caché es útil cuando las memorias caché están dañadas o tienen un estado incorrecto por algún motivo. Disponible a partir del SDK de .NET 7.

  • -f|--framework <FRAMEWORK>

    Publica la aplicación para el marco de trabajo de destino especificado. Debe especificar el marco de trabajo de destino en el archivo de proyecto.

  • --force

    Fuerza la resolución de todas las dependencias, incluso si la última restauración se realizó correctamente. Especificar esta marca es lo mismo que eliminar el archivo project.assets.json.

  • -?|-h|--help

    Imprime una descripción de cómo usar el comando.

  • --interactive

    Permite que el comando se detenga y espere una entrada o una acción del usuario. Por ejemplo, para completar la autenticación. Disponible desde el SDK de .NET Core 3.0.

  • --manifest <PATH_TO_MANIFEST_FILE>

    Especifica uno o varios manifiestos de destino que se usarán para recortar el conjunto de paquetes publicados con la aplicación. El archivo de manifiesto es parte de la salida del comando dotnet store. Para especificar varios manifiestos, agregue la opción --manifest para cada manifiesto.

  • --no-build

    No compila el proyecto antes de publicarlo. También establece la marca --no-restore de forma implícita.

  • --no-dependencies

    Omite las referencias de proyecto a proyecto y solo restaura el proyecto raíz.

  • --nologo

    No se muestra la pancarta de inicio ni el mensaje de copyright.

  • --no-restore

    No ejecuta una restauración implícita al ejecutar el comando.

  • -o|--output <OUTPUT_DIRECTORY>

    Especifica la ruta de acceso del directorio de salida.

    Si no se especifica, el valor predeterminado es [carpeta_de_archivo_de-_proyecto]./bin/[configuración]/[marco]/publish/ para un archivo ejecutable dependiente del marco y archivos binarios multiplataforma. El valor predeterminado es [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ para un archivo ejecutable autocontenido.

    En un proyecto web, si la carpeta de salida se encuentra en la carpeta del proyecto, los comandos dotnet publish posteriores dan como resultado carpetas de salida anidadas. Por ejemplo, si la carpeta del proyecto es myproject y la carpeta de salida de la publicación es myproject/publish, y ejecuta dotnet publish dos veces, la segunda ejecución coloca los archivos de contenido, como .config y .json, en myproject/publish/publish. Para evitar el anidamiento de carpetas de publicación, especifique una que no esté directamente en la carpeta del proyecto, o bien excluya la carpeta de publicación del proyecto. Para excluir una carpeta de publicación denominada publishoutput, agregue el elemento siguiente a un elemento PropertyGroup en el archivo .csproj:

    <DefaultItemExcludes>$(DefaultItemExcludes);publishoutput**</DefaultItemExcludes>

    • SDK de .NET 7.0.200 y versiones posteriores

      Si especifica la opción --output al ejecutar este comando en una solución, la CLI emitirá una advertencia (un error en la versión 7.0.200) debido a la semántica poco clara de la ruta de acceso de salida. No se permite la opción --output porque todas las salidas de todos los proyectos compilados se copiarían en el directorio especificado, que no es compatible con proyectos de varios destinos, así como con proyectos que tienen diferentes versiones de dependencias directas y transitivas. Para más información, consulte la opción Nivel de solución: la opción --output ya no es válida para los comandos relacionados con la compilación.

    • SDK de .NET Core 3.x y versiones posteriores

      Si se especifica una ruta de acceso relativa al publicar un proyecto, el directorio de salida generado es relativo al directorio de trabajo actual, no a la ubicación del archivo del proyecto.

      Si se especifica una ruta de acceso relativa al publicar una solución, todas las salidas de todos los proyectos van en la carpeta especificada relativa al directorio de trabajo actual. A fin de que la salida de la publicación vaya a carpetas independientes para cada proyecto, especifique una ruta de acceso relativa mediante el uso de la propiedad PublishDir de MSBuild en lugar de la opción --output. Por ejemplo, dotnet publish -p:PublishDir=.\publish envía la salida de publicación de cada proyecto a una carpeta publish en la carpeta que contiene el archivo del proyecto.

    • SDK de .NET Core 2.x

      Si se especifica una ruta de acceso relativa al publicar un proyecto, el directorio de salida generado es relativo a la ubicación del archivo del proyecto, no al directorio de trabajo actual.

      Si se especifica una ruta de acceso relativa al publicar una solución, la salida de cada proyecto va a una carpeta independiente relativa a la ubicación del archivo del proyecto. Si se especifica una ruta de acceso absoluta al publicar una solución, la salida de las publicaciones de todos los proyectos va a la carpeta especificada.

  • --os <OS>

    Especifica el sistema operativo (SO) de destino. Se trata de una sintaxis abreviada para establecer el identificador del entorno de ejecución (RID), donde el valor proporcionado se combina con el RID predeterminado. Por ejemplo, en un equipo win-x64, al especificar --os linux se establece el RID en linux-x64. Si usa esta opción, no use la opción -r|--runtime. Disponible a partir de .NET 6.

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

    Publica el entorno de ejecución de .NET con la aplicación para que no sea necesario instalarlo en el equipo de destino. El valor predeterminado es true si se especifica un identificador en tiempo de ejecución y el proyecto es de tipo ejecutable (no un proyecto de biblioteca). Para obtener más información, vea Publicación de aplicaciones de .NET y Publicación de aplicaciones de .NET con la CLI de .NET.

    Si se usa esta opción sin especificar true o false, el valor predeterminado es true. En ese caso, no coloque el argumento de la solución o el proyecto inmediatamente después de --self-contained, porque se espera que true o false estén en esa posición.

  • --no-self-contained

    Equivalente a --self-contained false.

  • --source <SOURCE>

    URI del origen del paquete NuGet que se usará durante la operación de restauración.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Publica la aplicación para un determinado entorno de tiempo de ejecución. Para obtener una lista de identificadores de tiempo de ejecución (RID), consulte el catálogo de RID. Para obtener más información, vea Publicación de aplicaciones de .NET y Publicación de aplicaciones de .NET con la CLI de .NET. Si usa esta opción, use --self-contained o --no-self-contained también.

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

    Especifica si se debe usar el registrador de terminal para la salida de compilación. El valor predeterminado es auto, que primero comprueba el entorno antes de habilitar el registro de terminal. La comprobación del entorno comprueba que el terminal sea capaz de usar características de salida modernas y no usa una salida estándar redirigida antes de habilitar el nuevo registrador. La opción on omite la comprobación del entorno y habilita el registro de terminal. La opción off omite la comprobación del entorno y usa el registrador de consola predeterminado.

    El registrador de terminal muestra la fase de restauración seguida de la fase de compilación. Durante cada fase, los proyectos en compilación actuales aparecen en la parte inferior del terminal. Cada proyecto que se compila genera una salida del destino de MSBuild que se está compilando actualmente y la cantidad de tiempo invertido en ese destino. Puede buscar en esta información para obtener más información sobre la compilación. Cuando un proyecto termina de compilarse, se escribe una única sección "compilación completada" en la que se captura lo siguiente:

    • El nombre del proyecto compilado.
    • La plataforma de destino (si es de destino múltiple).
    • El estado de esa compilación.
    • La salida principal de esa compilación (con hipervínculo).
    • Los diagnósticos generados para ese proyecto.

    Esta opción está disponible a partir de .NET 8.

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

    Establece RuntimeIdentifier en una plataforma portátil RuntimeIdentifier, en función de la que haya en la máquina. Esto sucede implícitamente con propiedades que requieren un RuntimeIdentifier, como SelfContained, PublishAot, PublishSelfContained, PublishSingleFile, y PublishReadyToRun. Si la propiedad se establece en false, esa resolución implícita ya no se producirá.

  • -v|--verbosity <LEVEL>

    Establece el nivel de detalle del comando. Los valores permitidos son q[uiet], m[inimal], n[ormal], d[etailed] y diag[nostic]. De manera predeterminada, es minimal. Para obtener más información, vea LoggerVerbosity.

  • --version-suffix <VERSION_SUFFIX>

    Define el sufijo de versión para reemplazar el asterisco (*) en el campo de versión del archivo de proyecto.

Ejemplos

  • Cree un archivo binario multiplataforma dependiente del marco para el proyecto en el directorio actual:

    dotnet publish

    A partir del SDK de .NET Core 3.0, en este ejemplo también se crea un ejecutable dependiente del marco para la plataforma actual.

  • Cree un ejecutable independiente para el proyecto en el directorio actual, para un tiempo de ejecución específico:

    dotnet publish --runtime osx-x64

    El RID debe estar en el archivo del proyecto.

  • Cree un ejecutable dependiente del marco para el proyecto en el directorio actual, para una plataforma específica:

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

    El RID debe estar en el archivo del proyecto. Este ejemplo se aplica al SDK de .NET Core 3.0 y versiones posteriores.

  • Publique el proyecto en el directorio actual, para un tiempo de ejecución específico y una plataforma de destino:

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

  • Publique el archivo del proyecto especificado:

    dotnet publish ~/projects/app1/app1.csproj

  • Publique la aplicación actual pero sin restaurar las referencias de proyecto a proyecto (P2P), solo el proyecto raíz, durante la operación de restauración:

    dotnet publish --no-dependencies

Vea también