Compartir a través de


Publicación de aplicaciones de .NET con la CLI de .NET

En este artículo se muestra cómo se puede publicar la aplicación .NET desde la línea de comandos. .NET proporciona tres maneras de publicar las aplicaciones. La implementación dependiente de la plataforma genera un archivo .dll multiplataforma que usa el entorno de ejecución de .NET instalado localmente. La implementación dependiente de la plataforma genera un archivo ejecutable específico de la plataforma que usa el entorno de ejecución de .NET instalado localmente. El archivo ejecutable independiente genera un archivo ejecutable específico de la plataforma e incluye una copia local del entorno de ejecución de .NET.

Para obtener información general sobre estos modos de publicación, consulte Implementación de aplicaciones .NET.

¿Busca ayuda rápida sobre el uso de la CLI? En la tabla siguiente se muestran algunos ejemplos de cómo publicar la aplicación. La plataforma de destino se puede especificar con el parámetro -f <TFM> o si edita el archivo de proyecto. Para más información, vea Conceptos básicos de publicación.

Modo de publicación Get-Help
Implementación dependiente de marco de trabajo dotnet publish -c Release -p:UseAppHost=false
Archivo ejecutable dependiente de la plataforma dotnet publish -c Release -r <RID> --self-contained false
dotnet publish -c Release
Implementación autocontenida dotnet publish -c Release -r <RID> --self-contained true

Nota:

  • El parámetro -c Release no es necesario. Se le proporciona como recordatorio para publicar la compilación de la versión de la aplicación.
  • En el SDK 3.1 de .NET o superior, el modo de publicación predeterminado cuando se ejecuta el comando dotnet publish básico es el archivo ejecutable dependiente de la plataforma.

Conceptos básicos de publicación

El valor <TargetFramework> del archivo de proyecto especifica la plataforma de destino predeterminada al publicar la aplicación. Se puede cambiar la plataforma de destino a cualquier moniker de la plataforma de destino (TFM). Por ejemplo, si en el proyecto se usa <TargetFramework>net8.0</TargetFramework>, se crea un archivo binario que tiene como destino .NET 8. El TFM especificado en esta configuración es el destino predeterminado que usa el comando dotnet publish.

Si quiere tener como destino más de una plataforma, puede establecer el valor <TargetFrameworks> en varios valores de TFM separados por punto y coma. Al crear la aplicación, se genera una compilación para cada plataforma de destino. Sin embargo, al publicar la aplicación, debe especificar la versión de la plataforma de destino con el comando dotnet publish -f <TFM>.

El modo BUILD-CONFIGURATION predeterminado es Depurar a menos que se cambie con el parámetro -c.

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

Dependencias nativas

Si la aplicación tiene dependencias nativas, es posible que no funcione en otro sistema operativo. Por ejemplo, si en la aplicación se usa la API Windows nativa, no se ejecutará en macOS o Linux. Tendrá que proporcionar código específico de la plataforma y compilar un archivo ejecutable para cada plataforma.

Tenga en cuenta también que, si una biblioteca a la que se hace referencia tiene una dependencia nativa, es posible que la aplicación no se ejecute en todas las plataformas. Pero es posible que un paquete NuGet al que se hace referencia incluya versiones específicas de la plataforma para controlar de forma automática las dependencias nativas necesarias.

Al distribuir una aplicación con dependencias nativas, es posible que tenga que usar el modificador dotnet publish -r <RID> para especificar la plataforma de destino para la que se quiere publicar. Para obtener una lista de identificadores de tiempo de ejecución, vea Catálogo de identificadores de entorno de ejecución (RID) de .NET Core.

En las secciones Archivo ejecutable dependiente de la plataforma e Implementación autocontenida se ofrece más información sobre los archivos binarios específicos de la plataforma.

Aplicación de ejemplo

Puede usar la siguiente aplicación para explorar los comandos de publicación. La aplicación se crea mediante la ejecución de los comandos siguientes en el terminal:

mkdir apptest1
cd apptest1
dotnet new console
dotnet add package Figgle

Es necesario cambiar el archivo Program.cs o Program.vb que genera la plantilla de consola por lo siguiente:

using System;

namespace apptest1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(Figgle.FiggleFonts.Standard.Render("Hello, World!"));
        }
    }
}
Module Program
    Sub Main(args As String())
        Console.WriteLine(Figgle.FiggleFonts.Standard.Render("Hello, World!"))
    End Sub
End Module

Al ejecutar la aplicación (dotnet run), se muestra el resultado siguiente:

  _   _      _ _         __        __         _     _ _
 | | | | ___| | | ___    \ \      / /__  _ __| | __| | |
 | |_| |/ _ \ | |/ _ \    \ \ /\ / / _ \| '__| |/ _` | |
 |  _  |  __/ | | (_) |    \ V  V / (_) | |  | | (_| |_|
 |_| |_|\___|_|_|\___( )    \_/\_/ \___/|_|  |_|\__,_(_)
                     |/

Implementación dependiente de marco de trabajo

Cuando la aplicación se publica como una FDD, se crea un archivo <PROJECT-NAME>.dll en la carpeta ./bin/<BUILD-CONFIGURATION>/<TFM>/publish/. Para ejecutar la aplicación, vaya a la carpeta de salida y use el comando dotnet <PROJECT-NAME>.dll.

La aplicación está configurada para tener como destino una versión específica de .NET. Es obligatorio que ese entorno de ejecución de .NET de destino esté en cualquier equipo donde se ejecute la aplicación. Por ejemplo, si la aplicación tiene como destino .NET Core 8, todas las máquinas en las que se ejecute la aplicación deben tener instalado el entorno de ejecución de .NET Core 8. Como se indica en la sección Conceptos básicos de publicación, se puede editar el archivo de proyecto para cambiar la plataforma de destino predeterminada o seleccionar más de una como destino.

Al publicar una FDD se crea una aplicación que realiza la puesta al día automática a la revisión de seguridad de .NET más reciente disponible en el sistema en el que se ejecuta la aplicación. Para más información sobre el enlace de versión en tiempo de compilación, consulte Selección de la versión de .NET que se va a usar.

Modo de publicación Get-Help
Implementación dependiente de marco de trabajo dotnet publish -c Release -p:UseAppHost=false

Archivo ejecutable dependiente de la plataforma

El archivo ejecutable dependiente de la plataforma (FDE) es el modo predeterminado para el comando dotnet publish básico. No es necesario especificar ningún otro parámetro, siempre que se quiera establecer como destino el sistema operativo actual.

En este modo, se crea un host ejecutable específico de la plataforma para hospedar la aplicación multiplataforma. Este modo es similar a FDD, ya que requiere un host en forma del comando dotnet. El nombre de archivo ejecutable de host varía según la plataforma y es similar a <PROJECT-FILE>.exe. Este archivo ejecutable se puede ejecutar directamente en lugar de llamar a dotnet <PROJECT-FILE>.dll, que sigue siendo una forma aceptable de ejecutar la aplicación.

La aplicación está configurada para tener como destino una versión específica de .NET. Es obligatorio que ese entorno de ejecución de .NET de destino esté en cualquier equipo donde se ejecute la aplicación. Por ejemplo, si la aplicación tiene como destino .NET 8, todas las máquinas en las que se ejecute la aplicación deben tener instalado el entorno de ejecución de .NET 8. Como se indica en la sección Conceptos básicos de publicación, se puede editar el archivo de proyecto para cambiar la plataforma de destino predeterminada o seleccionar más de una como destino.

Al publicar un FDE se crea una aplicación que realiza la puesta al día automática a la revisión de seguridad de .NET más reciente disponible en el sistema en el que se ejecuta la aplicación. Para más información sobre el enlace de versión en tiempo de compilación, consulte Selección de la versión de .NET que se va a usar.

Modo de publicación Get-Help
Archivo ejecutable dependiente de la plataforma dotnet publish -c Release -r <RID> --self-contained false
dotnet publish -c Release

Siempre que se usa el modificador -r, la ruta de acceso de la carpeta de salida cambia a: ./bin/<BUILD-CONFIGURATION>/<TFM>/<RID>/publish/

Si usa la aplicación de ejemplo, ejecute dotnet publish -f net6.0 -r win-x64 --self-contained false. Este comando crea el archivo ejecutable siguiente: ./bin/Debug/net6.0/win-x64/publish/apptest1.exe

Nota

Puede reducir el tamaño total de la implementación si habilita el modo de globalización invariable. Este modo es útil para las aplicaciones que no son globales y que pueden usar las convenciones de formato, las de mayúsculas y minúsculas, y el criterio de ordenación y la comparación de cadenas de la referencia cultural invariable. Para más información sobre el modo de globalización invariable y cómo habilitarlo, consulte Modo de globalización invariable de .NET.

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

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 propiedades AppHostDotNetSearch 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
  • EnvironmentVariables: valor de las variables de entorno DOTNET_ROOT[_<arch>]
  • 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, consulte AppHostDotNetSearch, AppHostRelativeDotNet y opciones de ubicación de instalación en apphost.

Implementación autocontenida

Cuando se publica una implementación autocontenida (SCD), el SDK de .NET crea un archivo ejecutable específico de la plataforma. La publicación de una SCD incluye todos los archivos de .NET necesarios para ejecutar la aplicación, pero no incluye las dependencias nativas de .NET (por ejemplo, .NET 6 en Linux o .NET 8 en Linux). Estas dependencias deben estar presentes en el sistema antes de ejecutar la aplicación.

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

Debe usar los modificadores siguientes con el comando dotnet publish para publicar una SCD:

Modo de publicación Get-Help
Implementación autocontenida dotnet publish -c Release -r <RID> --self-contained true

Sugerencia

  • En .NET 6 y versiones posteriores, puede reducir el tamaño total de las aplicaciones autocontenidas compatibles mediante la publicación recortada. Esta permite al recortador quitar partes del marco de trabajo y de los ensamblados a los que se hace referencia que no están en ninguna ruta de acceso de código o que potencialmente se hace referencia en la reflexión en tiempo de ejecución. Consulte Incompatibilidades de recorte para determinar si el recorte tiene sentido para la aplicación.
  • Puede reducir el tamaño total de la implementación si habilita el modo de globalización invariable. Este modo es útil para las aplicaciones que no son globales y que pueden usar las convenciones de formato, las de mayúsculas y minúsculas, y el criterio de ordenación y la comparación de cadenas de la referencia cultural invariable. Para más información sobre el modo de globalización invariable y cómo habilitarlo, vea Modo de globalización invariable de .NET Core.

Vea también