LuisLlamas Logo
aspnet-core-publish-deploy-produccion-iis-linux

Publicar ASP.NET Core en IIS o Linux con dotnet publish

  • 4 min
  • Intermedio

dotnet publish es el comando que prepara una aplicación .NET y sus dependencias para desplegarla.

Durante el desarrollo solemos pulsar F5 o escribir dotnet run. Eso ejecuta la aplicación con una configuración pensada para programar y depurar.

Para producción usamos normalmente una compilación Release, con las optimizaciones y los artefactos previstos para el despliegue.

Para ir a producción, necesitamos generar una versión Release: optimizada y empaquetada. El comando para esto es dotnet publish.

El comando básico

El comando más sencillo que puedes ejecutar en tu terminal es:

dotnet publish -c Release -o ./publish
Copied!

Desglosemos qué hace esto:

  1. -c Release: Compila en modo Release. El compilador de C# (Roslyn) aplicará optimizaciones agresivas para que tu código corra más rápido.
  2. -o ./publish: Guarda el resultado en la carpeta publish.

Dentro de esa carpeta verás los ensamblados, las dependencias, los archivos de configuración y, según el tipo de publicación, un ejecutable nativo. Ese es el conjunto de archivos que desplegamos.

Estrategias de publicación

En .NET moderno, tenemos dos formas principales de empaquetar la aplicación. Elegir la correcta depende de tu servidor.

Es la opción por defecto y no incluye el runtime completo.

  • Requisito: El servidor DEBE tener instalado el .NET Runtime de la versión objetivo (por ejemplo, .NET 10 si publicas para .NET 10).
  • Ventaja: El despliegue ocupa menos y varias aplicaciones pueden usar el mismo runtime instalado en el servidor.

Esta opción mete todo el Runtime de .NET dentro de tu carpeta de publicación.

  • Requisito: No necesita un runtime de .NET instalado, aunque el sistema operativo todavía debe cumplir las dependencias nativas de la plataforma elegida.
  • Desventaja: El tamaño crece mucho (100MB+ por una API simple).
  • Comando:
# Publicar para Linux 64 bits autocontenido
dotnet publish -c Release -r linux-x64 --self-contained true
Copied!

Kestrel

Cuando ejecutas tu API compilada (./MiApi.exe o dotnet MiApi.dll), quien está escuchando las peticiones HTTP es un servidor web llamado Kestrel.

Kestrel es un servidor web ligero, multiplataforma y extremadamente rápido (open source) que viene integrado en ASP.NET Core.

Kestrel puede exponerse directamente a Internet o colocarse detrás de un proxy inverso. IIS, Nginx, Apache o un balanceador pueden facilitar la terminación TLS, el reparto de carga, los logs de acceso y la integración con la infraestructura existente.

Por eso es habitual usar el patrón de proxy inverso, aunque no es obligatorio en todos los despliegues.

Arquitectura con proxy inverso

En lugar de exponer directamente la aplicación al puerto 80/443 público, ponemos un servidor o balanceador delante que recibe la petición y se la pasa a Kestrel.

  1. Instala el .NET Core Hosting Bundle en el servidor Windows. Esto instala el Runtime y un módulo para IIS (AspNetCoreModuleV2).
  2. Crea un sitio web en IIS y apunta a tu carpeta publish.
  3. El módulo de IIS se encargará de arrancar tu .exe en segundo plano y redirigir el tráfico.

Al hacer dotnet publish, se genera automáticamente un archivo web.config. No lo borres, es el que le dice a IIS cómo arrancar tu aplicación.

  1. Copia tus archivos al servidor (ej: /var/www/miapi).
  2. Crea un servicio Systemd (un archivo .service) para que tu app arranque sola si se reinicia el servidor.
[Unit]
Description=Mi API .NET

[Service]
WorkingDirectory=/var/www/miapi
ExecStart=/usr/bin/dotnet /var/www/miapi/MiApi.dll
Restart=always

[Install]
WantedBy=multi-user.target
Copied!
  1. Configura Nginx como Proxy Inverso para que escuche en el puerto 80 y redirija a localhost:5000 (donde escucha Kestrel).

Publicación en un solo archivo

Existe una opción muy atractiva para herramientas de consola, workers o despliegues concretos: empaquetar la aplicación en un único archivo .exe o binario de Linux.

dotnet publish -c Release -r win-x64 -p:PublishSingleFile=true --self-contained true
Copied!

El resultado es un solo fichero MiApi.exe. En APIs web puede ser útil, pero no siempre compensa: revisa tamaño, arranque, extracción de archivos nativos y compatibilidad con tu plataforma de despliegue.

Gestión de configuración en producción

Un error clásico es publicar el appsettings.Development.json o tener las cadenas de conexión de desarrollo en el appsettings.json base.

En producción, el orden de carga es:

  1. appsettings.json (Base).
  2. appsettings.Production.json (Sobrescribe).
  3. Variables de Entorno (Sobrescribe a todo lo anterior).

La mejor práctica en servidores (IIS/Linux/Docker) es NO tocar los archivos JSON. Usa variables de entorno en el servidor para definir la cadena de conexión y las claves secretas.

  • Windows: set ASPNETCORE_ENVIRONMENT=Production
  • Linux: export ASPNETCORE_ENVIRONMENT=Production

En esta página