Etiqueta: dotnet CLI

Hay algo que aprendí trabajando con desarrolladores que vienen de otros ecosistemas: subestiman la CLI de .NET. La ven como un atajo para no abrir Visual Studio, pero en realidad es la columna vertebral de todo el toolchain de .NET moderno. Los pipelines de CI/CD, los contenedores, los scripts de automatización — todo pasa por acá. En este artículo repaso las siete capacidades principales con ejemplos reales, desde crear una solución hasta monitorear un proceso en producción.

Un poco de contexto

Antes de que la CLI existiera en su forma actual, el ecosistema .NET dependía fuertemente de Visual Studio y de MSBuild estructurado para Windows. Eso generaba fragmentación: el desarrollador trabajaba en Windows con el IDE, el servidor de CI corría en Linux, y los scripts de deploy eran una mezcla de PowerShell y batch que nadie quería tocar. La CLI resolvió eso siendo un frontend unificado que orquesta MSBuild, NuGet y VSTest de manera consistente en cualquier plataforma.

1. Bootstrapping: dotnet new y dotnet sln

El punto de entrada de cualquier proyecto. dotnet new no es solo un generador de archivos — es un motor de plantillas que elimina el boilerplate inicial y estandariza la estructura de proyectos entre el equipo. dotnet sln maneja la interconexión de proyectos dentro de una solución, algo que antes requería editar XML a mano o depender del IDE.

# Crear una solución en blanco
dotnet new sln -n MiSistemaEnterprise

# Crear API y proyecto de pruebas
dotnet new webapi -n MiSistemaEnterprise.Api
dotnet new xunit -n MiSistemaEnterprise.Tests

# Vincular ambos a la solución
dotnet sln add ./MiSistemaEnterprise.Api/MiSistemaEnterprise.Api.csproj
dotnet sln add ./MiSistemaEnterprise.Tests/MiSistemaEnterprise.Tests.csproj

# Referenciar la API desde el proyecto de pruebas
dotnet add ./MiSistemaEnterprise.Tests/MiSistemaEnterprise.Tests.csproj \
  reference ./MiSistemaEnterprise.Api/MiSistemaEnterprise.Api.csproj

Esto es exactamente lo que corro cuando arranco un proyecto nuevo. Cinco comandos y tengo una solución con API, pruebas y referencias configuradas, sin abrir ningún IDE.

2. Gestión de Dependencias: dotnet add package

La interfaz de NuGet desde la terminal. Modifica el .csproj, descarga los binarios a la caché global y resuelve el árbol completo de dependencias transitivas. En pipelines de CI/CD esto es fundamental — no hay interfaz gráfica disponible, y este comando funciona igual en cualquier agente.

cd MiSistemaEnterprise.Api

# Instalar Polly para resiliencia con versión específica
dotnet add package Polly --version 8.3.0

# Ver todas las dependencias instaladas
dotnet list package

# Eliminar un paquete
dotnet remove package Polly

El --version explícito es importante en proyectos serios: evita que una actualización automática rompa algo en producción sin que nadie lo vea venir.

3. Compilación: dotnet build

dotnet build es la abstracción sobre MSBuild. Ejecuta automáticamente el restore de dependencias faltantes y compila el código a IL (Intermediate Language), generando los .dll listos para el runtime. El flag --nologo puede parecer cosmético, pero en logs de CI hace una diferencia real en la legibilidad.

# Compilar toda la solución en modo Release
dotnet build ../MiSistemaEnterprise.sln --configuration Release --nologo

# Limpiar artefactos anteriores (bin/ y obj/)
dotnet clean

4. Desarrollo Activo: dotnet watch

Esta es la que más impacto tiene en el día a día. Antes de dotnet watch, el ciclo era: guardar → detener el proceso → recompilar → reiniciar → probar. Repetido decenas de veces por hora. Con dotnet watch y Hot Reload, los cambios se reinyectan directamente en el proceso en ejecución sin perder el estado de la aplicación.

# Ejecutar la API en modo de observación
# Cualquier cambio guardado en un .cs se aplica instantáneamente
dotnet watch run --project ./MiSistemaEnterprise.Api.csproj

El ahorro de tiempo es real. En una jornada de desarrollo intenso, esos segundos por ciclo se acumulan en horas.

5. Pruebas Automatizadas: dotnet test

El runner de pruebas nativo de la CLI. Compatible con xUnit, NUnit y MSTest sin configuración adicional. Lo importante para CI/CD es la combinación de exportación en formato TRX (compatible con Azure DevOps, Jenkins) y la recolección de cobertura con Coverlet, que genera reportes que podés publicar directamente en el pipeline.

# Ejecutar pruebas con reporte TRX y cobertura de código
dotnet test ./MiSistemaEnterprise.Tests.csproj \
  --logger "trx;LogFileName=resultados.trx" \
  --collect:"XPlat Code Coverage"

6. Publicación y Despliegue: dotnet publish

El comando que resuelve el clásico «funciona en mi máquina». Empaqueta la aplicación, sus dependencias y opcionalmente el runtime de .NET en un artefacto desplegable. Hay dos modos principales:

• Framework-Dependent: requiere .NET instalado en el servidor. Más liviano.
• Self-Contained: incluye el runtime. Más pesado, pero sin dependencias externas en el servidor.

Con AOT (Ahead-of-Time), podés compilar directamente a código nativo de la plataforma, eliminando el runtime por completo.

# Publicar como ejecutable autocontenido para Linux x64
# Un único binario, con trimming para reducir el tamaño
dotnet publish ./MiSistemaEnterprise.Api.csproj \
  --configuration Release \
  --runtime linux-x64 \
  --self-contained true \
  /p:PublishSingleFile=true \
  /p:PublishTrimmed=true

En proyectos con contenedores, este comando va directo al Dockerfile: compilás con dotnet publish en la etapa de build y copiás el binario resultante a la imagen final. Imagen más pequeña, arranque más rápido.

7. Diagnóstico en Producción: dotnet tools

La capacidad menos conocida y la más poderosa cuando algo falla en producción. Las herramientas globales de .NET permiten monitorear y perfilar procesos en vivo, incluso en contenedores Linux, sin necesidad de instalar agentes externos ni reinicios.

Las tres que más uso:

• dotnet-counters: métricas en tiempo real (CPU, GC, ThreadPool, peticiones por segundo)
• dotnet-trace: trazas de CPU para identificar cuellos de botella
• dotnet-dump: volcados de memoria para analizar fugas o crashes

# Instalar la herramienta globalmente (una sola vez)
dotnet tool install --global dotnet-counters

# Listar procesos .NET en ejecución para obtener el PID
dotnet-counters ps

# Monitorear métricas del runtime en tiempo real para el proceso 1234
dotnet-counters monitor -p 1234 --counters System.Runtime

Tuve un caso donde la memoria de un servicio crecía progresivamente en producción sin un patrón claro. Con dotnet-counters identifiqué que las colecciones Gen2 del GC eran anormalmente frecuentes. Con dotnet-dump capturé el heap y encontré el objeto que se estaba reteniendo. Todo sin reiniciar el servicio ni afectar a los usuarios. Eso no tiene precio.

Resumen

La CLI de .NET no es un accesorio — es la herramienta central alrededor de la cual gira todo el ciclo de vida de una aplicación .NET moderna. Desde el primer dotnet new hasta el dotnet-counters monitor en producción, cada etapa tiene su comando y su propósito.

Si venís de un entorno donde todo pasaba por el IDE, mi recomendación es dedicarle una tarde a explorar estos comandos en un proyecto de prueba. La inversión se recupera rápido, especialmente en el momento en que tenés que diagnosticar algo en un servidor Linux sin interfaz gráfica.

¿Usás alguna herramienta de diagnóstico de la CLI que no esté en esta lista? Dejalo en los comentarios.