Compartir a través de

Introducción a la publicación de aplicaciones .NET

En este artículo se explican las distintas formas de publicar una aplicación .NET. Trata los modos de publicación, cómo generar archivos ejecutables y archivos binarios multiplataforma, y el impacto de cada enfoque en entornos de implementación y tiempo de ejecución. Puede publicar aplicaciones .NET mediante la CLI de .NET o Visual Studio.

Para obtener un breve tutorial sobre la publicación, consulte Tutorial: Publicación de una aplicación de consola de .NET con Visual Studio Code.

Para obtener un breve tutorial sobre la publicación, consulte Tutorial: Publicación de una aplicación de consola de .NET con Visual Studio.

¿Qué es la publicación?

Publicar una aplicación .NET significa compilar código fuente para crear un archivo ejecutable o binario, junto con sus dependencias y archivos relacionados, para su distribución. Después de la publicación, implemente la aplicación en un servidor, una plataforma de distribución, un contenedor o un entorno en la nube. El proceso de publicación prepara una aplicación para la implementación y el uso fuera de un entorno de desarrollo.

Modos de publicación

Hay dos maneras principales de publicar una aplicación. Algunos factores que influyen en esta decisión incluyen si el entorno de implementación tiene instalado el entorno de ejecución de .NET adecuado y si necesita características de compilación específicas que requieren la unión del entorno de ejecución con la aplicación. Los dos modos de publicación son:

  • Publicación autocontenida
    Este modo genera una carpeta de publicación que incluye un ejecutable específico de la plataforma que se usa para iniciar la aplicación, un binario compilado que contiene código de aplicación, las dependencias de la aplicación y el entorno de ejecución de .NET necesario para ejecutar la aplicación. El entorno que ejecuta la aplicación no necesita tener preinstalado el entorno de ejecución de .NET.

  • Publicación dependiente del marco de trabajo
    Este modo genera una carpeta de publicación que incluye un ejecutable opcional específico de la plataforma que se usa para iniciar la aplicación, un binario compilado que contiene código de aplicación y cualquier dependencia de la aplicación. El entorno que ejecuta la aplicación debe tener instalada una versión del entorno de ejecución de .NET que puede usar la aplicación.

Importante

Especifique la plataforma de destino con un identificador en tiempo de ejecución (RID). Para obtener más información sobre los RID, vea el Catálogo de identificadores de entorno de ejecución (RID) de .NET.

Conceptos básicos de publicación

La <TargetFramework> configuración del archivo de proyecto especifica el marco de destino predeterminado al publicar la aplicación. Puede cambiar la plataforma de destino a cualquier Moniker de plataforma de destino (TFM) válido. Por ejemplo, si el proyecto usa <TargetFramework>net9.0</TargetFramework>, se crea un binario destinado a .NET 9.

Si desea tener como destino más de un marco de trabajo, puede establecer la <TargetFrameworks> configuración en varios valores de TFM, separados por un punto y coma. Al compilar la aplicación, la aplicación se compila para cada marco de destino definido por el proyecto. Sin embargo, al publicar la aplicación, debe especificar la plataforma de destino:

El modo de configuración de compilación predeterminado es Release, a menos que se cambie con el -c parámetro .

dotnet publish -c Release -f net9.0

El directorio de salida predeterminado del dotnet publish comando es ./bin/<BUILD-CONFIGURATION>/<TFM>/publish/. Por ejemplo, dotnet publish -c Release -f net9.0 publica en ./bin/Release/net9.0/publish/. Sin embargo, puede optar por una ruta de acceso de salida simplificada y una estructura de carpetas para todas las salidas de compilación. Para obtener más información, consulte Diseño de salida de artefactos.

En Visual Studio, cree perfiles de publicación independientes para cada plataforma de destino.

Archivos binarios portátiles

Al publicar una aplicación .NET, puede tener como destino una plataforma específica o crear un archivo binario portátil. De forma predeterminada, incluso al crear un archivo binario portátil, .NET publica un archivo ejecutable específico de la plataforma ("apphost") junto con el archivo DLL portátil a menos que deshabilite explícitamente este comportamiento.

El archivo ejecutable específico de la plataforma se crea debido a la UseAppHost propiedad , que tiene truecomo valor predeterminado . Para publicar solo el archivo DLL portátil sin el archivo ejecutable específico de la plataforma, establezca UseAppHost en false en la línea de comandos (-p:UseAppHost=false) o como una propiedad de proyecto.

La ventaja de dirigirse a una plataforma específica es que puede controlar las dependencias nativas que la aplicación podría requerir, lo que garantiza la compatibilidad con los requisitos específicos de la plataforma de destino.

Dependencias nativas

Si la aplicación tiene dependencias nativas, es posible que no se ejecute en otro sistema operativo si se publica como binario portátil. Por ejemplo, las aplicaciones que dependen de la API de Windows no se ejecutan de forma nativa en macOS o Linux. Tendría que proporcionar código específico de la plataforma y compilar un ejecutable para cada plataforma.

Tenga en cuenta también, si una biblioteca a la que se hace referencia proporciona dependencias específicas de la plataforma, es posible que la aplicación no se ejecute en todas las plataformas. Sin embargo, al publicar y establecer como destino una plataforma específica, las dependencias específicas de la plataforma de un paquete NuGet se copian en la carpeta publish.

Para asegurarse de que la aplicación se publica con sus dependencias nativas, publique para una plataforma específica:

dotnet publish -c Release -r <RID>

  • -c Release

    Este modificador establece la configuración de compilación en Release, que está optimizada para la implementación de producción.

  • -r <RID>

    Este modificador usa un identificador en tiempo de ejecución (RID) para especificar la plataforma de destino y garantiza que se incluyan las dependencias nativas (si es necesario). Para obtener una lista de identificadores en tiempo de ejecución, consulte Catálogo de identificadores de tiempo de ejecución (RID).

  1. Haga clic con el botón derecho en el proyecto en el Explorador de soluciones y seleccione Publicar.
  2. Si esta es la primera vez que publica, seleccione Carpeta como destino de publicación y seleccione Siguiente.
  3. Elija una ubicación de carpeta o acepte el valor predeterminado y seleccione Finalizar.
  4. En el perfil de publicación, seleccione Mostrar toda la configuración.
  5. Establezca Tiempo de ejecución de destino en la plataforma deseada (por ejemplo, win-x64 para Windows de 64 bits).
  6. Seleccione Guardar y, a continuación, Publicar.

Para obtener una lista de identificadores en tiempo de ejecución, consulte Catálogo de identificadores de tiempo de ejecución (RID).

Referencia rápida

En la tabla siguiente se proporcionan ejemplos rápidos de cómo publicar la aplicación.

Modo de publicación Get-Help
Implementación dependiente del marco dotnet publish -c Release [-r <RID>]
Implementación dependiente del marco (DLL) dotnet publish -c Release -p:UseAppHost=false
Implementación independiente dotnet publish -c Release [-r <RID>] --self-contained true
Implementación de un solo archivo dotnet publish -c Release [-r <RID>] -p:PublishSingleFile=true
Implementación nativa de AOT dotnet publish -c Release [-r <RID>] -p:PublishAot=true
Implementación readyToRun dotnet publish -c Release [-r <RID>] -p:PublishReadyToRun=true
Implementación de contenedores dotnet publish -c Release [-r <RID>] -t:PublishContainer

Implementación dependiente del marco

La implementación dependiente del marco es el modo predeterminado al publicar desde la CLI o Visual Studio. En este modo, se crea un ejecutable específico de la plataforma que se puede usar para iniciar la aplicación. El ejecutable específico de la plataforma se denomina algo similar a myapp.exe en Windows o simplemente myapp en otras plataformas.

La aplicación está configurada para tener como destino una versión específica de .NET. Ese entorno de ejecución de .NET de destino debe estar en el entorno donde se ejecuta la aplicación. Por ejemplo, si la aplicación tiene como destino .NET 9, cualquier entorno en el que se ejecute la aplicación debe tener instalado el entorno de ejecución de .NET 9.

La publicación de una implementación dependiente del marco crea una aplicación que se reenvía automáticamente a la revisión de seguridad de .NET más reciente disponible en el entorno que ejecuta la aplicación. Para obtener más información sobre el enlace de versiones en tiempo de compilación, consulte Selección de la versión de .NET que se va a usar.

Ventajas

  • Implementación pequeña: solo se distribuyen la aplicación y sus dependencias. El entorno en el que se ejecuta la aplicación ya debe tener instalado el entorno de ejecución de .NET.
  • Multiplataforma: la aplicación y cualquier . La biblioteca basada en NET se ejecuta en otros sistemas operativos.
  • Usa el tiempo de ejecución revisado más reciente: la aplicación usa el tiempo de ejecución más reciente instalado en el entorno.

Desventajas

  • Requiere preinstalar el entorno de ejecución: la aplicación solo se puede ejecutar si la versión de .NET que tiene como destino ya está instalada en el entorno.
  • .NET podría cambiar: el entorno en el que se ejecuta la aplicación podría usar un entorno de ejecución de .NET más reciente, lo que podría cambiar el comportamiento de la aplicación.

Inicio de aplicaciones dependientes del marco

Hay dos maneras de ejecutar aplicaciones dependientes del marco: a través del ejecutable específico de la plataforma ("apphost") y a través de dotnet myapp.dll. Puede ejecutar el ejecutable apphost directamente en lugar de llamar a dotnet myapp.dll, que sigue siendo una manera aceptable de ejecutar la aplicación. Siempre que sea posible, se recomienda usar apphost. Hay una serie de ventajas para usar apphost:

  • Los ejecutables aparecen como ejecutables de plataforma nativa estándar.
  • Los nombres ejecutables se conservan en los nombres de proceso, lo que significa que las aplicaciones se pueden reconocer fácilmente en función de sus nombres.
  • Dado que apphost es un binario nativo, se pueden adjuntar activos nativos como manifiestos.
  • Apphost tiene disponibles mitigaciones de seguridad de bajo nivel aplicadas de forma predeterminada, lo que hace que sea más seguro. Por ejemplo, la tecnología de aplicación de control del flujo (CET) con la pila sombra está habilitada de forma predeterminada a partir de .NET 9. Las mitigaciones aplicadas a dotnet son el denominador común más bajo de todos los entornos de ejecución admitidos.

Publicar

dotnet publish -c Release [-r <RID>]

  • -c Release

    Este modificador establece la configuración de compilación en Release, que está optimizada para la implementación de producción.

  • -r <RID>

    Este modificador usa un identificador en tiempo de ejecución (RID) para especificar la plataforma de destino y garantiza que se incluyan las dependencias nativas (si es necesario). Para obtener una lista de identificadores en tiempo de ejecución, consulte Catálogo de identificadores de tiempo de ejecución (RID).

O explícitamente:

dotnet publish -c Release [-r <RID>] --self-contained false

  • --self-contained false

    Este modificador indica explícitamente al SDK de .NET que cree una implementación dependiente del marco.

  1. Haga clic con el botón derecho en el proyecto en el Explorador de soluciones y seleccione Publicar.
  2. Si esta es la primera vez que publica, seleccione Carpeta como destino de publicación y seleccione Siguiente.
  3. Elija una ubicación de carpeta o acepte el valor predeterminado y seleccione Finalizar.
  4. En el perfil de publicación, seleccione Mostrar toda la configuración.
  5. Establezca Modo de implementaciónen dependiente del marco (este es el valor predeterminado).
  6. Establezca Tiempo de ejecución de destino en la plataforma deseada (por ejemplo, win-x64 para Windows de 64 bits).
  7. Seleccione Guardar y, a continuación, Publicar.

Configuración del comportamiento de búsqueda de instalación de .NET

De forma predeterminada, apphost detecta y usa un entorno de ejecución de .NET instalado globalmente, con ubicaciones de instalación que varían según la plataforma. Para obtener más información sobre las ubicaciones de detección e instalación en tiempo de ejecución, consulte Solución de problemas de errores de inicio de aplicaciones.

La ruta de acceso del entorno de ejecución de .NET también se puede personalizar por ejecución. La DOTNET_ROOT variable de entorno se puede usar para apuntar a la ubicación personalizada. Para obtener más información sobre todas las DOTNET_ROOT opciones de configuración, consulte Variables de entorno de .NET.

En general, el procedimiento recomendado para usar DOTNET_ROOT consiste en:

  1. Borre DOTNET_ROOT primero las variables de entorno, es decir, todas las variables de entorno que comienzan con el texto DOTNET_ROOT.
  2. Establezca DOTNET_ROOT, y solo DOTNET_ROOT, en la ruta de acceso de destino.
  3. Ejecute el apphost de destino.

En .NET 9 y versiones posteriores, puede configurar las rutas de búsqueda de instalación de .NET del ejecutable publicado a través de las AppHostDotNetSearch propiedades y AppHostRelativeDotNet .

AppHostDotNetSearch permite especificar una o varias ubicaciones en las que el archivo ejecutable buscará una instalación de .NET:

  • AppLocal: carpeta del ejecutable de la aplicación
  • AppRelative: ruta de acceso relativa al ejecutable de la aplicación
  • EnvironmentVariable: valor de las variables de DOTNET_ROOT[_<arch>] entorno
  • Global: ubicaciones de instalación globales registradas y predeterminadas

AppHostRelativeDotNet especifica la ruta de acceso relativa al archivo ejecutable que se buscará cuando AppHostDotNetSearch contenga AppRelative.

Para obtener más información, vea AppHostDotNetSearchOpciones de ubicación de instalación de , AppHostRelativeDotNete instalar en apphost.

Implementación de DLL multiplataforma

Como alternativa, puede publicar la aplicación como un archivo DLL multiplataforma sin un ejecutable específico de la plataforma. En este modo, se crea un myapp.dll archivo en la carpeta de salida de publicación. Para ejecutar la aplicación, vaya a la carpeta de salida y use el dotnet myapp.dll comando .

Para publicar como un archivo DLL multiplataforma:

dotnet publish -c Release -p:UseAppHost=false

  • -c Release

    Este modificador establece la configuración de compilación en Release, que está optimizada para la implementación de producción.

  • -p:UseAppHost=false

    Esta propiedad deshabilita la creación de un archivo ejecutable específico de la plataforma, lo que produce solo el archivo DLL portátil.

  1. Haga clic con el botón derecho en el proyecto en el Explorador de soluciones y seleccione Publicar.
  2. Si esta es la primera vez que publica, seleccione Carpeta como destino de publicación y seleccione Siguiente.
  3. Elija una ubicación de carpeta o acepte el valor predeterminado y seleccione Finalizar.
  4. En el perfil de publicación, seleccione Mostrar toda la configuración.
  5. Establezca Modo de implementaciónen dependiente del marco.
  6. Desactive Producir un solo archivo.
  7. Establezca Tiempo de ejecución de destino en Portable (o deje en blanco).
  8. Seleccione Guardar y, a continuación, Publicar.

Implementación independiente

Al publicar una implementación autocontenida (SCD), el proceso de publicación crea un ejecutable específico de la plataforma. La publicación de un SCD incluye todos los archivos .NET necesarios para ejecutar la aplicación, pero no incluye las dependencias nativas de .NET. Estas dependencias deben estar presentes en el entorno antes de que se ejecute la aplicación.

Al publicar un SCD, se crea una aplicación que no se reenvía a la revisión de seguridad de .NET más reciente disponible. Para obtener más información sobre el enlace de versiones en tiempo de compilación, consulte Selección de la versión de .NET que se va a usar.

Ventajas

  • Control de la versión de .NET: controle qué versión de .NET se implementa con la aplicación.
  • Destino específico de la plataforma: dado que la aplicación debe publicarse para cada plataforma, está claro dónde se ejecuta la aplicación.

Desventajas

  • Implementaciones más grandes: dado que la aplicación incluye el entorno de ejecución de .NET y todas las dependencias, el tamaño de descarga y el espacio de disco duro necesario es mayor que una implementación dependiente del marco.
  • Más difícil de actualizar la versión de .NET: el entorno de ejecución de .NET solo se puede actualizar liberando una nueva versión de la aplicación.

Sugerencia

Puede reducir el tamaño total de las aplicaciones autocontenida compatibles mediante la publicación recortada o habilitando el modo invariable de globalización. Para obtener más información sobre el modo invariable de globalización, vea Modo invariable de globalización de .NET.

Publicar

dotnet publish -c Release -r <RID> --self-contained true

  • -c Release

    Este modificador establece la configuración de compilación en Release, que está optimizada para la implementación de producción.

  • -r <RID>

    Este modificador usa un identificador en tiempo de ejecución (RID) para especificar la plataforma de destino y garantiza que se incluyan las dependencias nativas (si es necesario). Para obtener una lista de identificadores en tiempo de ejecución, consulte Catálogo de identificadores de tiempo de ejecución (RID).

  • --self-contained true

    Este modificador indica al SDK de .NET que cree un archivo ejecutable como una implementación independiente (SCD).

  1. Haga clic con el botón derecho en el proyecto en el Explorador de soluciones y seleccione Publicar.
  2. Si esta es la primera vez que publica, seleccione Carpeta como destino de publicación y seleccione Siguiente.
  3. Elija una ubicación de carpeta o acepte el valor predeterminado y seleccione Finalizar.
  4. En el perfil de publicación, seleccione Mostrar toda la configuración.
  5. Establezca Modo de implementaciónen Independiente.
  6. Establezca Tiempo de ejecución de destino en la plataforma deseada (por ejemplo, win-x64 para Windows de 64 bits).
  7. Seleccione Guardar y, a continuación, Publicar.

Implementación de un solo archivo

Al publicar la aplicación como una implementación de un solo archivo, todos los archivos dependientes de la aplicación se agrupan en un único binario. Este modelo de implementación está disponible para aplicaciones independientes y dependientes del marco, lo que proporciona una opción atractiva para implementar y distribuir la aplicación como un único archivo.

Las aplicaciones de un solo archivo siempre son específicas del sistema operativo y de la arquitectura. Debe publicar para cada configuración, como Linux x64, Linux Arm64, Windows x64, etc.

Ventajas

  • Distribución simplificada: implemente y distribuya la aplicación como un único archivo ejecutable.
  • Desorden de archivos reducido: todas las dependencias se agrupan, lo que elimina la necesidad de administrar varios archivos.
  • Implementación sencilla: copie un único archivo para implementar la aplicación.

Desventajas

  • Tamaño de archivo mayor: el único archivo incluye todas las dependencias, lo que hace que sea mayor que los archivos individuales.
  • Inicio más lento: los archivos se deben extraer en tiempo de ejecución, lo que puede afectar al rendimiento del inicio.
  • Específico de la plataforma: debe publicar archivos independientes para cada plataforma de destino.

La implementación de un solo archivo se puede combinar con otras optimizaciones, como el recorte y la compilación ReadyToRun para una mayor optimización.

Para obtener más información sobre la implementación de un solo archivo, consulte Implementación de un solo archivo.

Publicar

dotnet publish -c Release -r <RID> -p:PublishSingleFile=true

  • -c Release

    Este modificador establece la configuración de compilación en Release, que está optimizada para la implementación de producción.

  • -r <RID>

    Este modificador usa un identificador en tiempo de ejecución (RID) para especificar la plataforma de destino y garantiza que se incluyan las dependencias nativas (si es necesario). Para obtener una lista de identificadores en tiempo de ejecución, consulte Catálogo de identificadores de tiempo de ejecución (RID).

  • -p:PublishSingleFile=true

    Esta propiedad agrupa todos los archivos dependientes de la aplicación en un único binario.

  1. Haga clic con el botón derecho en el proyecto en el Explorador de soluciones y seleccione Publicar.
  2. Si esta es la primera vez que publica, seleccione Carpeta como destino de publicación y seleccione Siguiente.
  3. Elija una ubicación de carpeta o acepte el valor predeterminado y seleccione Finalizar.
  4. En el perfil de publicación, seleccione Mostrar toda la configuración.
  5. Establezca Modo de implementación en Independiente o dependiente del marco.
  6. Establezca Tiempo de ejecución de destino en la plataforma deseada (por ejemplo, win-x64 para Windows de 64 bits).
  7. Active Producir un solo archivo.
  8. Seleccione Guardar y, a continuación, Publicar.

Implementación nativa de AOT

La implementación nativa de AOT compila la aplicación directamente en código nativo, lo que elimina la necesidad de un entorno de ejecución. Esta opción de publicación usa el modo de implementación independiente , ya que el código nativo compilado debe incluir todo lo necesario para ejecutar la aplicación. Esto da como resultado tiempos de inicio más rápidos y un uso reducido de memoria, pero incluye algunas limitaciones en las características admitidas.

Ventajas

  • Inicio rápido: no se necesita ninguna compilación JIT en tiempo de ejecución, lo que conduce a un inicio de aplicación más rápido.
  • Uso reducido de memoria: menor superficie de memoria en comparación con las aplicaciones .NET tradicionales.
  • Sin dependencia en tiempo de ejecución: la aplicación se ejecuta sin necesidad de instalación en tiempo de ejecución de .NET.
  • Tamaño de implementación más pequeño: a menudo menor que la implementación independiente con el entorno de ejecución completo.

Desventajas

  • Compatibilidad con marcos limitados: no todas las características y bibliotecas de .NET son compatibles con AOT nativo.
  • Tiempos de compilación más largos: la compilación en código nativo tarda más tiempo que las compilaciones normales.
  • Específico de la plataforma: debe compilarse por separado para cada plataforma de destino y arquitectura.
  • Limitaciones de depuración: experiencia de depuración más compleja en comparación con las aplicaciones de .NET normales.

Para obtener más información sobre la implementación de AOT nativa, consulte Implementación de AOT nativa.

Publicar

dotnet publish -c Release -r <RID> -p:PublishAot=true

  • -c Release

    Este modificador establece la configuración de compilación en Release, que está optimizada para la implementación de producción.

  • -r <RID>

    Este modificador usa un identificador en tiempo de ejecución (RID) para especificar la plataforma de destino y garantiza que se incluyan las dependencias nativas (si es necesario). Para obtener una lista de identificadores en tiempo de ejecución, consulte Catálogo de identificadores de tiempo de ejecución (RID).

  • -p:PublishAot=true

    Esta propiedad habilita la compilación AOT nativa, que compila la aplicación directamente en código nativo.

La publicación nativa de AOT debe configurarse en el archivo del proyecto. No se puede habilitar a través de la interfaz de usuario de publicación de Visual Studio.

  1. En el Explorador de soluciones, haga clic con el botón derecho en el proyecto y seleccione Editar archivo de proyecto.

  2. Agregue la siguiente propiedad a :<PropertyGroup>

    <PublishAot>true</PublishAot>

  3. Guarde el archivo del proyecto.

  4. Haga clic con el botón derecho en el proyecto en el Explorador de soluciones y seleccione Publicar.

  5. Si esta es la primera vez que publica, seleccione Carpeta como destino de publicación y seleccione Siguiente.

  6. Elija una ubicación de carpeta o acepte el valor predeterminado y seleccione Finalizar.

  7. En el perfil de publicación, seleccione Mostrar toda la configuración.

  8. Establezca Modo de implementaciónen Independiente.

  9. Establezca Tiempo de ejecución de destino en la plataforma deseada (por ejemplo, win-x64 para Windows de 64 bits).

  10. Seleccione Guardar y, a continuación, Publicar.

Para obtener más información sobre la implementación de AOT nativa, consulte Implementación de AOT nativa.

Implementación readyToRun

Al publicar la aplicación con la compilación ReadyToRun, los ensamblados de la aplicación se compilan como formato ReadyToRun (R2R). R2R es una forma de compilación anticipada (AOT) que mejora el rendimiento de inicio al reducir la cantidad de trabajo que el compilador Just-In-Time (JIT) necesita hacer a medida que se carga la aplicación. Esta opción de publicación se puede usar con modos de implementaciónindependientes y dependientes del marco.

Los archivos binarios ReadyToRun contienen código de lenguaje intermedio (IL) y la versión nativa del mismo código. Aunque los archivos binarios de R2R son más grandes que los ensamblados normales, proporcionan un mejor rendimiento de inicio.

Ventajas

  • Tiempo de inicio mejorado: la aplicación dedica menos tiempo a ejecutar el compilador JIT durante el inicio.
  • Mejor rendimiento de primer uso: latencia reducida para la ejecución por primera vez de rutas de acceso de código.
  • Compatible con el código existente: funciona con la mayoría de las bibliotecas y marcos de .NET sin modificaciones.
  • Implementación flexible: se puede combinar con la implementación dependiente del marco y los modos de implementación autocontenida .

Desventajas

  • Tamaño mayor: la aplicación es mayor en el disco debido a la inclusión de IL y código nativo.
  • Tiempos de compilación más largos: la compilación tarda más tiempo que la publicación estándar.
  • Optimizaciones específicas de la plataforma: las mejores mejoras de rendimiento requieren tener como destino plataformas específicas.

Publicar

dotnet publish -c Release -r <RID> -p:PublishReadyToRun=true

  • -c Release

    Este modificador establece la configuración de compilación en Release, que está optimizada para la implementación de producción.

  • -r <RID>

    Este modificador usa un identificador en tiempo de ejecución (RID) para especificar la plataforma de destino y garantiza que se incluyan las dependencias nativas (si es necesario). Para obtener una lista de identificadores en tiempo de ejecución, consulte Catálogo de identificadores de tiempo de ejecución (RID).

  • -p:PublishReadyToRun=true

    Esta propiedad habilita la compilación ReadyToRun, lo que mejora el rendimiento de inicio mediante la compilación previa de ensamblados.

  1. Haga clic con el botón derecho en el proyecto en el Explorador de soluciones y seleccione Publicar.
  2. Si esta es la primera vez que publica, seleccione Carpeta como destino de publicación y seleccione Siguiente.
  3. Elija una ubicación de carpeta o acepte el valor predeterminado y seleccione Finalizar.
  4. En el perfil de publicación, seleccione Mostrar toda la configuración.
  5. Establezca Modo de implementación en Independiente o dependiente del marco.
  6. Establezca Tiempo de ejecución de destino en la plataforma deseada (por ejemplo, win-x64 para Windows de 64 bits).
  7. Active Enable ReadyToRun compilation (Habilitar compilación ReadyToRun).
  8. Seleccione Guardar y, a continuación, Publicar.

Para obtener más información sobre la implementación de ReadyToRun, consulte Compilación ReadyToRun.

Implementación de contenedores

Al publicar la aplicación como contenedor, el SDK de .NET empaqueta la aplicación y sus dependencias en una imagen de contenedor sin necesidad de un Dockerfile independiente. Este modo de implementación crea una imagen de contenedor completa que se puede ejecutar en cualquier entorno de ejecución de contenedor, como Docker o Podman. La implementación de contenedores simplifica el proceso de contenedor mediante la eliminación de la necesidad de escribir y mantener dockerfiles al mismo tiempo que proporciona imágenes base optimizadas.

A partir del SDK de .NET 8.0.200, la compatibilidad con contenedores se incluye de forma predeterminada y no requiere paquetes NuGet adicionales. En el caso de las aplicaciones de consola, es posible que tenga que habilitar explícitamente la compatibilidad con contenedores estableciendo la EnableSdkContainerSupport propiedad trueen .

Sugerencia

Para obtener más información sobre la configuración del proyecto relacionada con los contenedores, consulte Containerize a .NET app reference (Referencia de una aplicación de .NET).

Ventajas

  • Contenedorización simplificada: no es necesario escribir ni mantener dockerfiles para escenarios básicos.
  • Imágenes base optimizadas: usa imágenes base optimizadas y proporcionadas por Microsoft con las últimas actualizaciones de seguridad.
  • Entorno coherente: garantiza un entorno en tiempo de ejecución coherente en todo el desarrollo, las pruebas y la producción.
  • Distribución sencilla: las imágenes de contenedor se pueden compartir e implementar fácilmente en distintos entornos.
  • Aislamiento de plataforma: las aplicaciones se ejecutan en contenedores aislados, lo que reduce los conflictos entre las aplicaciones.

Desventajas

  • Dependencia del entorno de ejecución del contenedor: el entorno de destino debe tener instalado un entorno de ejecución de contenedor.
  • Tamaño de imagen: las imágenes de contenedor suelen ser mayores que otros métodos de implementación.
  • Curva de aprendizaje: requiere la comprensión de los conceptos de contenedor y las herramientas.
  • Personalización limitada: menor flexibilidad en comparación con los dockerfiles personalizados para escenarios complejos.

Publicar

dotnet publish -c Release [-r <RID>] /t:PublishContainer

  • -c Release

    Este modificador establece la configuración de compilación en Release, que está optimizada para la implementación de producción.

  • -r <RID>

    Este modificador usa un identificador en tiempo de ejecución (RID) para especificar la plataforma de destino y garantiza que se incluyan las dependencias nativas (si es necesario). Para obtener una lista de identificadores en tiempo de ejecución, consulte Catálogo de identificadores de tiempo de ejecución (RID).

  • -t:PublishContainer

    Este destino publica la aplicación como una imagen de contenedor.

También puede usar el enfoque de perfil de publicación:

dotnet publish -c Release [-r <RID>] -p:PublishProfile=DefaultContainer

  • -p:PublishProfile=DefaultContainer

    Este perfil desencadena el proceso de publicación de contenedores.

  1. Haga clic con el botón derecho en el proyecto en el Explorador de soluciones y seleccione Publicar.
  2. Seleccione Container Registry como destino de publicación y seleccione Siguiente.
  3. Elija el registro de contenedor de destino (como Azure Container Registry, Docker Hub o Registro genérico) y seleccione Siguiente.
  4. Configure los detalles y la autenticación de la conexión del Registro.
  5. En el perfil de publicación, seleccione Mostrar toda la configuración.
  6. Establezca el modo de implementación en independiente o dependiente del marco en función de sus necesidades.
  7. Establezca Tiempo de ejecución de destino en la plataforma deseada (por ejemplo, linux-x64 para contenedores de Linux).
  8. Configure opciones específicas del contenedor, como el nombre y las etiquetas de la imagen.
  9. Seleccione Guardar y, a continuación, Publicar.

Para más información sobre la implementación de contenedores, consulte Introducción a la creación de contenedores del SDK de .NET.

Consulte también

  • Last updated on