Compartir por

dotnet publish

Este artículo se aplica a: ✔️ SDK de .NET 6 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>|<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>] [-p|--property:<PROPERTYNAME>=<VALUE>]
    [-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

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 siguientes recursos:

  • Código de lenguaje intermedio (IL) en un ensamblado con una extensión de dll.
  • Un archivo .deps.json que incluye todas las dependencias del proyecto.
  • Un archivo .runtimeconfig.json que especifica el entorno 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 en la carpeta de salida.

La salida del comando dotnet publish está lista para su implementación en un sistema de hospedaje (por ejemplo, un servidor, PC, Mac, portátil) para su ejecución. Es la única manera oficialmente compatible de 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 tener o no instalado el entorno de ejecución compartido de .NET en él. Para obtener más información, consulte Introducción a la publicación de aplicaciones .NET.

Restauración implícita

No es necesario ejecutar dotnet restore porque se ejecuta implícitamente por todos los comandos que requieren que se produzca una restauración, como dotnet new, dotnet build, dotnet run, dotnet run, dotnet publish, dotnet packy . Para deshabilitar la restauración implícita, use la opción --no-restore.

El comando dotnet restore sigue siendo útil en determinados escenarios en los que la restauración explícitamente tiene sentido, como compilaciones de integración continua en Azure DevOps Services o en 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, consulte la documentación de dotnet restore.

MSBuild

El comando dotnet publish llama a MSBuild, que invoca el destino de Publish. Si la propiedad IsPublishable está establecida en false para un proyecto determinado, el destino de Publish no se puede invocar y el comando dotnet publish solo ejecuta el de restauración de dotnet implícito en el proyecto.

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

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

Archivos .pubxml

También puede establecer propiedades relacionadas con la publicación haciendo referencia a un archivo de .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, se omiten. MSBuild busca de forma predeterminada en la carpeta de Properties/PublishProfiles y supone que 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 de .pubxml de :

  • Visual Studio usa PublishUrl para indicar el destino Publicar.
  • la CLI usa PublishDir para indicar el destino Publicar.

Si desea que el escenario funcione en todos los lugares, puede inicializar ambas propiedades en el mismo valor del archivo .pubxml. Cuando se resuelve el problema de GitHub dotnet/sdk#20931, solo debe establecerse una de estas propiedades.

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

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

Propiedades de MSBuild

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

  • PublishReadyToRun

    Compila ensamblados de aplicación como formato ReadyToRun (R2R). R2R es una forma de compilación anticipada (AOT). Para obtener más información, consulte imágenes ReadyToRun.

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

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

  • PublishSingleFile

    Empaqueta la aplicación en un archivo ejecutable de archivo único específico de la plataforma. Para obtener más información sobre la publicación de archivos únicos, consulte el documento de diseño del agrupador de archivos único . Cuando esta propiedad se establece trueen , la PublishSelfContained propiedad se establece trueimplícitamente en .

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

  • PublishTrimmed

    Recorta las bibliotecas sin usar para reducir el tamaño de implementación de una aplicación al publicar un ejecutable autocontenido. Para obtener más información, consulte Recorte de implementaciones independientes y ejecutables. Disponible desde el SDK de .NET 6.

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

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

Descargas de manifiestos de carga de trabajo

Al ejecutar este comando, inicia una descarga en segundo plano asincrónica de manifiestos de publicidad para cargas de trabajo. Si la descarga todavía se está ejecutando cuando finaliza este comando, se detiene la descarga. Para obtener más información, consulte manifiestos de publicidad.

Argumentos

PROJECT | SOLUTION | FILE

Archivo de proyecto o solución o de C# (aplicación basada en archivos) en el que operar. Si no se especifica un archivo, MSBuild busca en el directorio actual un proyecto o solución.

  • PROJECT es la ruta de acceso y el nombre de archivo de un archivo de proyecto de C#, F# o Visual Basic, o la ruta de acceso a un directorio que contiene un archivo de proyecto de C#, F#o Visual Basic.

  • SOLUTION es la ruta de acceso y el nombre de archivo de una solución (.sln o extensión .slnx) o la ruta de acceso a un directorio que contiene un archivo de solución.

  • FILE es un argumento agregado en .NET 10. Ruta de acceso y nombre de archivo de una aplicación basada en archivos. Las aplicaciones basadas en archivos se incluyen en un único archivo que se compila y se ejecuta sin un archivo de proyecto (.csproj) correspondiente. Para obtener más información, consulte Compilación de aplicaciones de C# basadas en archivos.

Opciones

  • -a|--arch <ARCHITECTURE>

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

  • --artifacts-path <ARTIFACTS_DIR>

    Todos los archivos de salida de compilación del comando ejecutado se incluirán en subcarpetas en la ruta de acceso especificada, separadas por el proyecto. Para obtener más información, vea diseño de salida de artefactos . Disponible desde el SDK de .NET 8.

  • -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 configuración de Release de forma predeterminada para los proyectos cuyo TargetFramework está establecido en net8.0 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 las memorias caché es útil cuando las memorias caché pueden estar dañadas o incorrectas por algún motivo. Disponible desde el SDK de .NET 7.

  • -f|--framework <FRAMEWORK>

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

  • --force

    Obliga a resolver todas las dependencias incluso si la última restauración se realizó correctamente. Especificar esta marca es la misma que la eliminación del archivo project.assets.json.

  • --interactive

    Permite que el comando se detenga y espere a la entrada o acción del usuario. Por ejemplo, para completar la autenticación.

  • --manifest <PATH_TO_MANIFEST_FILE>

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

  • --no-build

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

  • --no-dependencies

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

  • --nologo

    No muestra el banner 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 [project_file_folder]/bin/[configuration]/[framework]/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 ejecutable autocontenida.

    En un proyecto web, si la carpeta de salida está en la carpeta del proyecto, los comandos sucesivos dotnet publish dan como resultado carpetas de salida anidadas. Por ejemplo, si la carpeta del proyecto es myproject, y la carpeta de salida de publicación es myproject/publishy ejecuta dotnet publish dos veces, la segunda ejecución coloca archivos de contenido como .config y .json archivos en myproject/publish/publish. Para evitar anidar carpetas de publicación, especifique una carpeta de publicación que no directamente en la carpeta del proyecto o excluya la carpeta publish del proyecto. Para excluir una carpeta de publicación denominada publishoutput, agregue el siguiente elemento 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 obtener más información, consulte opción de --output de nivel de solución ya no es válida para los comandos relacionados con la compilación.

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

      Si 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 especifica una ruta de acceso relativa al publicar una solución, toda la salida de todos los proyectos entra en la carpeta especificada en relación con el directorio de trabajo actual. Para que la salida de publicación vaya a carpetas independientes para cada proyecto, especifique una ruta de acceso relativa mediante la propiedad msbuild PublishDir 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.

  • --os <OS>

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

  • --sc|--self-contained

    Publique el entorno de ejecución de .NET con la aplicación para que el entorno de ejecución no tenga que instalarse en la máquina de destino.

  • -p|--property:<PROPERTYNAME>=<VALUE>

    Establece una o varias propiedades de MSBuild. Especifique varias propiedades delimitadas por punto y coma o repitiendo la opción:

    --property:<NAME1>=<VALUE1>;<NAME2>=<VALUE2>
--property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>

  • --no-self-contained

    Publique la aplicación como una aplicación dependiente del marco. Se debe instalar un entorno de ejecución de .NET compatible en la máquina de destino para ejecutar la aplicación.

  • --source <SOURCE>

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

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Publica la aplicación para un tiempo de ejecución determinado. Para obtener una lista de identificadores en tiempo de ejecución (RID), consulte el catálogo rid de . Para obtener más información, consulte Introducción a la publicación de aplicaciones .NET. Si usa esta opción, use también --self-contained o --no-self-contained.

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

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

    Registrador de terminal muestra la fase de restauración seguida de la fase de compilación. Durante cada fase, los proyectos de creación actuales aparecen en la parte inferior del terminal. Cada proyecto que crea salidas tanto el destino de MSBuild que se está compilando como la cantidad de tiempo invertido en ese destino. Puede buscar esta información para obtener más información sobre la compilación. Cuando un proyecto ha terminado de compilarse, se escribe una única sección "compilación completada" que captura:

    • Nombre del proyecto compilado.
    • La plataforma de destino (si es de destino múltiple).
    • Estado de esa compilación.
    • Salida principal de esa compilación (que es hipervínculo).
    • Cualquier diagnóstico generado para ese proyecto.

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

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

    Use el tiempo de ejecución actual como tiempo de ejecución de destino.

  • -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]. El valor predeterminado es minimal. Para obtener más información, consulte LoggerVerbosity.

  • --version-suffix <VERSION_SUFFIX>

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

  • -?|-h|--help

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

Ejemplos

  • Cree un binario multiplataforma dependiente del marco de trabajo 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 una ejecutable dependiente del marco de trabajo para la plataforma actual.

  • Cree una ejecutable independiente para el proyecto en el directorio actual para un entorno 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 de 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 entorno de ejecución y un marco de destino específicos:

    dotnet publish --framework net8.0 --runtime osx-x64

  • Publique el archivo de proyecto especificado:

    dotnet publish ~/projects/app1/app1.csproj

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

    dotnet publish --no-dependencies

  • Publique el programa de C# basado en archivos app.cs en el directorio actual:

    dotnet publish app.cs

    Se ha agregado compatibilidad con programas basados en archivos en el SDK de .NET 10.0.100.

Consulte también

  • Last updated on