dotnet publish para ejecutables sin SDK

Resumen

Compilar y publicar una aplicación .NET desde la línea de comandos te permite generar ejecutables interoperables que funcionan en Windows, Linux o Mac sin depender del entorno de desarrollo. Aquí verás cómo pasar de un proyecto de consola a un archivo distribuible usando dotnet build, dotnet run y dotnet publish, con foco en la opción self-contained para empaquetar todo lo necesario.

¿Cómo se compila un proyecto .NET desde la terminal?

Antes de publicar, necesitas compilar. El comando dotnet build toma tu proyecto y crea o recrea la carpeta bin, que contiene el archivo compilado listo para ejecutarse.

Una vez dentro de la carpeta del proyecto (en este caso nuget), basta con escribir el comando y presionar Enter. La terminal genera el assembly y deja el binario disponible para ejecución.

¿Qué hace dotnet build? Compila tu proyecto y genera la carpeta bin con el archivo .dll listo para ejecutarse. Es el paso previo a correr la aplicación.

¿Cuál es la diferencia entre dotnet build y dotnet run?

dotnet run ejecuta la aplicación, pero antes corre dotnet build por defecto. Esto significa que no necesitas lanzar ambos comandos manualmente: con dotnet run ya compilas y ejecutas en un solo paso.

Es el flujo que probablemente has usado durante todo el desarrollo. Práctico, pero todavía depende de la línea de comandos del SDK.

¿Qué hace dotnet publish y dónde queda el ejecutable?

Al ejecutar dotnet publish dentro de la carpeta del proyecto, .NET genera la versión compilada lista para distribuir. La terminal te muestra la ruta exacta donde quedó el resultado.

La ubicación típica es bin/release/net8, y dentro encontrarás el archivo nuget.dll. Ese .dll es el assembly de tu aplicación. Puedes correrlo con:

  • dotnet nuget.dll desde la carpeta donde se encuentra.
  • El resultado es idéntico al de dotnet run.
  • Sigue dependiendo del SDK de .NET para funcionar.

Y aquí viene lo interesante: este es justamente el mecanismo interno que usa dotnet run por debajo.

¿Cómo genero un ejecutable que no dependa del SDK?

Para liberarte del SDK necesitas una publicación self-contained. El comando es:

bash dotnet publish --release --self-contained win-x64

Desglosando los parámetros:

  • --release indica que uses la carpeta release en lugar de la de debug.
  • --self-contained empaqueta el runtime junto con tu aplicación.
  • win-x64 define el sistema operativo y arquitectura objetivo (Windows 64 bits).

El proceso tarda un poco más que un build normal, así que ten paciencia mientras termina.

¿Dónde queda el ejecutable autocontenido y cómo se ejecuta?

Al finalizar, aparece una nueva carpeta llamada win-x64 dentro de bin/release/net8. Si entras y ejecutas ls, vas a ver un montón de DLLs sumadas al archivo principal: nuget.exe.

Todas esas DLLs son las dependencias que tu proyecto necesita para correr sin un entorno .NET instalado previamente. Para lanzar la aplicación, basta con escribir:

bash ./nuget.exe

El resultado es el mismo que veías con dotnet run, pero con una diferencia clave: ya no dependes de la línea de comandos del SDK. Puedes mover esa carpeta donde quieras, compartirla con otra persona o copiarla a otro equipo, y la aplicación se ejecutará igual.

¿Qué es una publicación self-contained en .NET? Es un empaquetado que incluye el runtime junto con tu aplicación, para que se ejecute en máquinas que no tienen .NET instalado. Ideal para distribuir software final.

¿Por qué se considera al .NET una plataforma interoperable?

Gracias a la universalidad del .NET, el mismo proceso funciona si cambias el target: puedes generar ejecutables para Linux, Mac o Windows ajustando el parámetro de arquitectura. Quien reciba tu carpeta solo necesita tener el runtime de .NET instalado (o ni eso, si publicaste en modo self-contained).

Eso te da aplicaciones ejecutables verdaderamente portables, sin importar el sistema operativo de destino.

Conceptos clave de la publicación en .NET

Antes de cerrar, vale la pena fijar las ideas técnicas que aparecieron:

  • Assembly: el archivo .dll generado tras compilar, que contiene el código intermedio de tu aplicación.
  • Carpeta bin: directorio donde .NET coloca los archivos compilados, organizados por configuración (debug o release) y target framework (como net8).
  • Runtime de .NET: el componente mínimo que un equipo necesita para ejecutar aplicaciones .NET cuando no usas self-contained.
  • RID (Runtime Identifier): el identificador como win-x64 que define el sistema operativo y arquitectura del ejecutable final.

¿Has probado publicar tu aplicación para otro sistema operativo? Cuéntame en los comentarios qué target usaste y cómo te fue con la distribución.