Cli | The .NET Blog

dotnet new WinUI: Crea apps de Windows sin tocar Visual Studio

Emiliano Montesdeoca — Wed, 27 May 2026 00:00:00 +0000

El desarrollo con WinUI solía requerir Visual Studio. Eso está cambiando: Microsoft ha publicado plantillas de proyectos y elementos de código abierto para WinUI que funcionan con dotnet new, incorporando el desarrollo de aplicaciones Windows al flujo de trabajo estándar de la CLI.

Empezar en tres comandos

# Instalar las plantillas
dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates

# Crear una app NavigationView
dotnet new winui-navview -n MyApp

# Ejecutarla
cd MyApp
dotnet run

Sin Visual Studio, sin configuración manual del proyecto. La aplicación se ejecuta con dotnet run.

Qué incluye

Plantilla en blanco (dotnet new winui) — un punto de partida moderno con una barra de título Fluent ya configurada, icono de app actualizado con recurso .ico, y valores predeterminados correctos para modo claro/oscuro. Mejor que la antigua plantilla en blanco que te dejaba configurar lo básico tú mismo.

Plantilla NavigationView (dotnet new winui-navview) — el patrón de navegación maestro-detalle, completamente configurado con un NavigationView, barra de título moderna y estructura de navegación multipágina. Sigue la silueta estándar de apps Windows para aplicaciones basadas en navegación. Si estás construyendo algo con navegación lateral, empieza aquí.

Ambas plantillas siguen las siluetas de apps Windows — patrones modernos de Fluent Design para diseño, navegación y estructura visual — desde el primer momento.

Por qué importa para desarrolladores que no usan Visual Studio

Los desarrolladores de WinUI que usan VS Code, Rider o herramientas de línea de comandos han estado desatendidos. Las plantillas existentes de Visual Studio no se podían usar fuera de VS — había que recrear manualmente la estructura del proyecto y configurar lo básico.

Estas plantillas son de código abierto (ver WindowsAppSDK PR #6407), desarrolladas a partir de comentarios de la comunidad, y disponibles ahora. El soporte para Visual Studio está en curso — estas mismas plantillas eventualmente funcionarán allí también.

Para equipos que quieran automatizar la configuración de sus proyectos WinUI, integrarla en CI, o simplemente usar un editor diferente a Visual Studio, esta es una mejora significativa.

Post original: Introducing dotnet new WinUI templates

Cosmos DB Shell Está en Vista Previa Pública — Y Tiene un Servidor MCP Integrado

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

Si alguna vez has tenido que ir y venir entre una pestaña del portal, una muestra de SDK y un script a medio terminar solo para responder una pregunta de Cosmos DB, ya conoces la fricción que este proyecto está diseñado para eliminar.

Azure Cosmos DB Shell acaba de entrar en vista previa pública. Es una CLI de código abierto con sintaxis tipo bash y — la parte que lo hace interesante — un servidor MCP integrado.

Qué lo Hace Diferente de Otras CLIs de Base de Datos

La CLI en sí es útil: comandos familiares, soporte para scripts, integración CI/CD. Esa parte es lo mínimo esperado para una herramienta de base de datos orientada a desarrolladores.

La parte interesante es la integración del servidor MCP. Cada comando que expone la CLI se convierte en una herramienta MCP que tus agentes de IA pueden llamar. No hay ninguna capa de API personalizada, ni código de integración que escribir. Tu agente puede:

Navegar por las jerarquías de bases de datos con cd, ls, pwd
Ejecutar consultas SQL con query y obtener resultados estructurados
Crear y modificar elementos con create item, update, rm
Gestionar bases de datos y contenedores con mkdb, mkcon, rmdb, rmcon
Inspeccionar el contexto actual con endpoint, pwd

El cambio clave: tu agente no está hablando con una API de Cosmos DB — está hablando con la misma interfaz de shell que usas tú. Los comandos son deterministas, auditables y de código abierto para que puedas inspeccionar exactamente qué está pasando.

La Base de Código Abierto Importa

Esto no es un servicio gestionado de caja negra. El shell es de código abierto, lo que significa:

Los equipos de seguridad pueden auditar la implementación
Los equipos de plataforma pueden hacer fork y ampliarlo para sus estándares específicos
Los desarrolladores pueden contribuir con mejoras que beneficien a todos

Para los equipos empresariales que adoptan herramientas de IA, “¿podemos ver exactamente cómo funciona?” es cada vez menos un requisito opcional. El código abierto aquí es un diferenciador significativo.

Tres Escenarios que Se Vuelven Más Fáciles

Análisis inteligente de datos — conecta un agente al shell, haz preguntas en lenguaje natural, obtén resultados de consultas estructurados. El agente se encarga de la construcción de la consulta; el shell se encarga de la ejecución.

Gestión autónoma de datos — los flujos de trabajo que necesitan crear, actualizar o eliminar datos en Cosmos DB pueden hacerlo a través de las herramientas MCP sin necesitar una integración personalizada.

Supervisión y alertas en tiempo real — un agente puede consultar contenedores periódicamente, comparar resultados y mostrar anomalías a través del canal de notificación que tenga sentido.

La interfaz MCP hace que estos escenarios sean composables con cualquier plataforma de IA que hable MCP — no solo las herramientas de Microsoft.

Para Empezar

El shell está en vista previa pública. Instálalo, configura tu conexión de Cosmos DB y habilita el servidor MCP. Desde allí, cualquier host de agente compatible con MCP puede descubrir y usar las herramientas.

Post original: Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

Windows App Dev CLI v0.3: F5 desde la terminal y automatización de UI para agentes

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Esta publicación fue traducida automáticamente. Para la versión original, haz clic aquí.

La experiencia F5 de Visual Studio es fantástica. Pero tener que abrir VS solo para lanzar y depurar una app Windows empaquetada es excesivo cuando estás en un pipeline de CI, ejecutando un workflow automatizado, o — cada vez más — cuando un agente de IA está haciendo las pruebas.

Windows App Development CLI v0.3 acaba de salir y lo aborda directamente con dos funciones destacadas: winapp run y winapp ui.

winapp run: F5 desde cualquier sitio

winapp run toma una carpeta de app sin empaquetar y un manifiesto, y hace todo lo que VS hace en un debug launch: registra un paquete loose, lanza la app y preserva el LocalState entre re-deploys.

# Construye tu app, luego ejecútala como app empaquetada
winapp run ./bin/Debug

Funciona para WinUI, WPF, WinForms, Console, Avalonia y más. Los modos están pensados tanto para desarrolladores como para workflows automatizados:

--detach: Lanza y devuelve el control a la terminal inmediatamente. Perfecto para CI/automation.
--unregister-on-exit: Limpia el paquete registrado al cerrar la app. Ejecuciones de test limpias.
--debug-output: Captura mensajes OutputDebugString y excepciones en tiempo real. Añade --symbols para PDBs del Microsoft Symbol Server.

Nuevo paquete NuGet: dotnet run para apps empaquetadas

Para desarrolladores .NET hay un nuevo paquete NuGet: Microsoft.Windows.SDK.BuildTools.WinApp.

Añádelo al proyecto (o deja que winapp init lo haga), y dotnet run maneja todo el inner loop: build, preparar un paquete loose-layout, registrar en Windows y lanzar — todo en un paso.

# Deja que winapp init lo configure
winapp init

# O instala directamente
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

Funciona con WinUI, WPF, WinForms, Console, Avalonia. Sin comandos adicionales, sin registro manual. Solo dotnet run.

winapp ui: UI Automation desde la línea de comandos

Este es el que abre los escenarios agénticos. winapp ui te da acceso completo de UI Automation a cualquier app Windows en ejecución — WPF, WinForms, Win32, Electron, WinUI3 — todo desde la terminal.

Lo que puedes hacer:

Listar todas las ventanas de nivel superior
Navegar el árbol completo de UI Automation de cualquier ventana
Buscar elementos por nombre, tipo o ID de automatización
Hacer clic, invocar y establecer valores
Tomar capturas de pantalla
Esperar a que aparezcan elementos — ideal para sincronización de tests

Combina winapp ui con winapp run y tienes un workflow completo build → lanzar → verificar desde la terminal. Un agente puede ejecutar tu app, inspeccionar el estado de UI, interactuar con ella programáticamente y validar el resultado.

Otras novedades

winapp unregister: Elimina un paquete sideloaded cuando terminas.
winapp manifest add-alias: Añade un uap5:AppExecutionAlias para lanzar la app por nombre desde la terminal.
Tab completion: Configura completado con un solo comando para PowerShell.
Package.appxmanifest por defecto: Ahora winapp init crea Package.appxmanifest (convención VS) en lugar de appxmanifest.xml.

Cómo obtenerlo

winget install Microsoft.WinAppCli
# o
npm install -g @microsoft/winappcli

La CLI está en preview pública. Consulta el repositorio en GitHub para documentación completa y el anuncio original para todos los detalles.

Deja de vigilar tu terminal: el modo desacoplado de Aspire cambia el flujo de trabajo

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Cada vez que ejecutas un AppHost de Aspire, tu terminal desaparece. Bloqueada. Ocupada hasta que presionas Ctrl+C. ¿Necesitas ejecutar un comando rápido? Abre otra pestaña. ¿Quieres revisar los logs? Otra pestaña. Es una pequeña fricción que se acumula rápido.

Aspire 13.2 soluciona esto. James Newton-King escribió todos los detalles, y honestamente, esta es una de esas funcionalidades que cambia inmediatamente tu forma de trabajar.

Modo desacoplado: un comando, terminal de vuelta

aspire start

Ese es el atajo para aspire run --detach. Tu AppHost arranca en segundo plano y recuperas tu terminal de inmediato. Sin pestañas extra. Sin multiplexor de terminal. Solo tu prompt, listo para usar.

Gestionando lo que está en ejecución

La cuestión es que ejecutar en segundo plano solo es útil si puedes gestionar lo que hay ahí fuera. Aspire 13.2 incluye un conjunto completo de comandos CLI para exactamente eso:

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

Esto convierte el CLI de Aspire en un gestor de procesos completo. Puedes iniciar múltiples AppHosts, verificar su estado, seguir sus logs y apagarlos — todo desde una sola sesión de terminal.

Combínalo con el modo aislado

El modo desacoplado se combina naturalmente con el modo aislado. ¿Quieres ejecutar dos instancias del mismo proyecto en segundo plano sin conflictos de puertos?

aspire start --isolated
aspire start --isolated

Cada uno obtiene puertos aleatorios, secretos separados y su propio ciclo de vida. Usa aspire ps para ver ambos, aspire stop para detener el que ya no necesites.

Por qué esto es enorme para los agentes de código

Aquí es donde se pone realmente interesante. Un agente de código trabajando en tu terminal ahora puede:

Iniciar la app con aspire start
Consultar su estado con aspire describe
Revisar logs con aspire logs para diagnosticar problemas
Detenerla con aspire stop cuando termine

Todo sin perder la sesión de terminal. Antes del modo desacoplado, un agente que ejecutara tu AppHost se bloqueaba a sí mismo en su propia terminal. Ahora puede iniciar, observar, iterar y limpiar — exactamente como querrías que funcione un agente autónomo.

El equipo de Aspire se volcó en esto. Ejecutar aspire agent init configura un archivo de habilidades de Aspire que enseña estos comandos a los agentes. Así, herramientas como el agente de código de Copilot pueden gestionar tus cargas de trabajo de Aspire directamente.

Para cerrar

El modo desacoplado es una mejora de flujo de trabajo disfrazada de un simple flag. Dejas de cambiar contexto entre terminales, los agentes dejan de bloquearse a sí mismos, y los nuevos comandos CLI te dan visibilidad real de lo que está en ejecución. Es práctico, es limpio, y hace que el ciclo de desarrollo diario sea notablemente más fluido.

Lee el post completo para todos los detalles y obtén Aspire 13.2 con aspire update --self.

azd update — Un solo comando para gobernar todos tus gestores de paquetes

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

¿Conoces ese mensaje de “Hay una nueva versión de azd disponible” que aparece cada pocas semanas? ¿Ese que ignoras porque no recuerdas si instalaste azd con winget, Homebrew o ese script de curl que ejecutaste hace seis meses? Bueno, eso por fin tiene solución.

Microsoft acaba de lanzar azd update — un único comando que actualiza Azure Developer CLI a la última versión sin importar cómo lo instalaste originalmente. Windows, macOS, Linux — da igual. Un solo comando.

Cómo funciona

azd update

Eso es todo. Si quieres acceso anticipado a nuevas funcionalidades, puedes cambiar a la build diaria de insiders:

azd update --channel daily
azd update --channel stable

El comando detecta tu método de instalación actual y usa el mecanismo de actualización apropiado internamente. Se acabó el “espera, ¿usé winget o choco en esta máquina?”

El pequeño detalle

azd update viene a partir de la versión 1.23.x. Si estás en una versión anterior, necesitarás hacer una última actualización manual usando tu método de instalación original. Después de eso, azd update se encarga de todo en adelante.

Comprueba tu versión actual con azd version. Si necesitas una instalación desde cero, la documentación de instalación te cubre.

Por qué importa

Es una pequeña mejora de calidad de vida, pero para los que usamos azd a diario para desplegar agentes de IA y apps de Aspire en Azure, estar actualizado significa menos momentos de “ese bug ya estaba corregido en la última versión”. Una cosa menos en la que pensar.

Lee el anuncio completo y el análisis más detallado de Jon Gallant para más contexto.

.NET Aspire 13.2 Quiere Ser el Mejor Amigo de Tu Agente de IA

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

¿Conoces ese momento cuando tu agente de IA escribe código sólido, te emocionas, y luego todo se desmorona cuando intenta ejecutar la cosa? Conflictos de puertos, procesos fantasma, variables de entorno incorrectas — de repente tu agente está quemando tokens depurando problemas de arranque en vez de construir funcionalidades.

El equipo de Aspire acaba de publicar un post muy bien pensado sobre exactamente este problema, y su respuesta es convincente: Aspire 13.2 está diseñado no solo para humanos, sino para agentes de IA.

El problema es real

Los agentes de IA son increíbles escribiendo código. Pero enviar una app full-stack funcional involucra mucho más que generar archivos. Necesitas iniciar servicios en el orden correcto, gestionar puertos, configurar variables de entorno, conectar bases de datos y obtener retroalimentación cuando algo se rompe. Ahora mismo, la mayoría de agentes manejan todo esto por prueba y error — ejecutando comandos, leyendo errores, intentando de nuevo.

Le metemos instrucciones en Markdown, skills personalizados y prompts para guiarlos, pero son impredecibles, no se pueden compilar y cuestan tokens solo para parsear. El equipo de Aspire dio en el clavo con la idea central: los agentes necesitan compiladores y APIs estructuradas, no más Markdown.

Aspire como infraestructura para agentes

Esto es lo que Aspire 13.2 trae a la mesa del desarrollo agéntico:

Todo tu stack en código tipado. El AppHost define tu topología completa — API, frontend, base de datos, caché — en TypeScript o C# compilable:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Un agente puede leer esto para entender la topología de la app, agregar recursos, conectar componentes y compilar para verificar. El compilador le dice inmediatamente si algo está mal. Sin adivinanzas, sin prueba y error con archivos de configuración.

Un solo comando para gobernarlos a todos. En vez de que los agentes malabareen docker compose up, npm run dev y scripts de arranque de bases de datos, todo es simplemente aspire start. Todos los recursos se lanzan en el orden correcto, en los puertos correctos, con la configuración correcta. Los procesos de larga duración tampoco cuelgan al agente — Aspire los gestiona.

Modo aislado para agentes en paralelo. Con --isolated, cada ejecución de Aspire obtiene sus propios puertos aleatorios y secretos de usuario separados. ¿Tienes múltiples agentes trabajando en git worktrees? No colisionarán. Esto es enorme para herramientas como los agentes en segundo plano de VS Code que crean entornos paralelos.

Ojos de agente a través de telemetría. Aquí es donde se pone realmente potente. El CLI de Aspire expone datos OpenTelemetry completos durante el desarrollo — trazas, métricas, logs estructurados. Tu agente no solo lee la salida de consola esperando lo mejor. Puede rastrear una petición fallida entre servicios, perfilar endpoints lentos e identificar exactamente dónde se rompen las cosas. Eso es observabilidad de nivel producción en el ciclo de desarrollo.

La analogía de los parachoques de boliche

El equipo de Aspire usa una gran analogía: piensa en Aspire como los parachoques de una pista de boliche para agentes de IA. Si el agente no es perfecto (y no lo será), los parachoques evitan que tire canaletas. La definición del stack previene mala configuración, el compilador atrapa errores, el CLI maneja la gestión de procesos y la telemetría provee el ciclo de retroalimentación.

Combina esto con algo como Playwright CLI, y tu agente puede realmente usar tu app — haciendo clic en flujos, revisando el DOM, viendo cosas rotas en telemetría, arreglando el código, reiniciando y probando de nuevo. Construir, ejecutar, observar, arreglar. Ese es el ciclo de desarrollo autónomo que hemos estado persiguiendo.

Primeros pasos

¿Nuevo en Aspire? Instala el CLI desde get.aspire.dev y sigue la guía de inicio.

¿Ya usas Aspire? Ejecuta aspire update --self para obtener la 13.2, luego apunta tu agente de código favorito a tu repo. Te sorprenderá lo mucho más lejos que llega con los guardrails de Aspire.

Para cerrar

Aspire 13.2 ya no es solo un framework para aplicaciones distribuidas — se está convirtiendo en infraestructura esencial para agentes. Definiciones de stack estructuradas, arranque con un comando, ejecuciones paralelas aisladas y telemetría en tiempo real le dan a los agentes de IA exactamente lo que necesitan para pasar de escribir código a enviar apps.

Lee el post completo del equipo de Aspire para todos los detalles y videos de demostración.

El Modo Aislado de Aspire Resuelve la Pesadilla de Conflictos de Puertos en Desarrollo Paralelo

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Si alguna vez intentaste ejecutar dos instancias del mismo proyecto al mismo tiempo, conoces el dolor. El puerto 8080 ya está en uso. El puerto 17370 está ocupado. Mata algo, reinicia, malabarea variables de entorno — es un asesino de productividad.

Este problema está empeorando, no mejorando. Los agentes de IA crean git worktrees para trabajar de forma independiente. Los agentes en segundo plano levantan entornos separados. Los desarrolladores hacen checkout del mismo repo dos veces para ramas de funcionalidades. Cada uno de estos escenarios choca con la misma pared: dos instancias de la misma app peleando por los mismos puertos.

Aspire 13.2 resuelve esto con un solo flag. James Newton-King del equipo de Aspire escribió todos los detalles, y es una de esas funcionalidades de “¿por qué no teníamos esto antes?”

La solución: `--isolated`

aspire run --isolated

Eso es todo. Cada ejecución obtiene:

Puertos aleatorios — no más colisiones entre instancias
Secretos de usuario aislados — cadenas de conexión y claves API permanecen separados por instancia

Sin reasignación manual de puertos. Sin malabarismo de variables de entorno. Cada ejecución obtiene un entorno limpio y libre de colisiones automáticamente.

Escenarios reales donde esto brilla

Múltiples checkouts. Tienes una rama de funcionalidad en un directorio y un bugfix en otro:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Ambos se ejecutan sin conflictos. El dashboard muestra qué está corriendo y dónde.

Agentes en segundo plano en VS Code. Cuando el agente en background de Copilot Chat crea un git worktree para trabajar en tu código de forma independiente, puede necesitar ejecutar tu AppHost de Aspire. Sin --isolated, eso es una colisión de puertos con tu worktree principal. Con él, ambas instancias simplemente funcionan.

El skill de Aspire que viene con aspire agent init instruye automáticamente a los agentes a usar --isolated cuando trabajan en worktrees. Así que el agente en background de Copilot debería manejar esto de forma nativa.

Tests de integración junto al desarrollo. ¿Necesitas ejecutar tests contra un AppHost en vivo mientras sigues construyendo funcionalidades? El modo aislado le da a cada contexto sus propios puertos y configuración.

Cómo funciona internamente

Cuando pasas --isolated, el CLI genera un ID de instancia único para la ejecución. Esto impulsa dos comportamientos:

Aleatorización de puertos — en vez de vincularse a puertos predecibles definidos en la configuración de tu AppHost, el modo aislado elige puertos aleatorios disponibles para todo — el dashboard, los endpoints de servicio, todo. El service discovery se ajusta automáticamente, así que los servicios se encuentran entre sí sin importar qué puertos les tocaron.
Aislamiento de secretos — cada ejecución aislada obtiene su propio almacén de secretos de usuario, identificado por el ID de instancia. Las cadenas de conexión y claves API de una ejecución no se filtran a otra.

Tu código no necesita cambios. El service discovery de Aspire resuelve los endpoints en tiempo de ejecución, así que todo se conecta correctamente sin importar la asignación de puertos.

Cuándo usarlo

Usa --isolated cuando ejecutes múltiples instancias del mismo AppHost simultáneamente — ya sea desarrollo paralelo, tests automatizados, agentes de IA o git worktrees. Para desarrollo de instancia única donde prefieras puertos predecibles, el aspire run regular sigue funcionando bien.

Para cerrar

El modo aislado es una funcionalidad pequeña que resuelve un problema real y cada vez más común. A medida que el desarrollo asistido por IA nos empuja hacia más flujos paralelos — múltiples agentes, múltiples worktrees, múltiples contextos — la capacidad de simplemente levantar otra instancia sin pelear por puertos es esencial.

Lee el post completo para todos los detalles técnicos y pruébalo con aspire update --self para obtener la 13.2.

Aspire 13.2 incluye una CLI de documentación — y tu agente de IA también puede usarla

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

¿Conocés ese momento cuando estás metido hasta el cuello en un Aspire AppHost, conectando integraciones, y necesitás verificar exactamente qué parámetros espera la integración de Redis? Hacés alt-tab al navegador, buscás por aspire.dev, entrecerrás los ojos mirando los docs de la API, y volvés a tu editor. Contexto perdido. Flujo roto.

Aspire 13.2 acaba de lanzar una solución para eso. La CLI aspire docs te permite buscar, explorar y leer documentación oficial de Aspire directamente desde tu terminal. Y como está respaldada por servicios reutilizables, los agentes de IA y skills pueden usar los mismos comandos para consultar docs en lugar de alucinar APIs que no existen.

El problema que esto realmente resuelve

David Pine lo clava en el post original: los agentes de IA eran terribles ayudando a los desarrolladores a construir apps con Aspire. Recomendaban dotnet run en vez de aspire run, referenciaban learn.microsoft.com para docs que viven en aspire.dev, sugerían paquetes NuGet desactualizados, y — mi favorito personal — alucinaban APIs que no existen.

¿Por qué? Porque Aspire fue específico de .NET por mucho más tiempo del que lleva siendo políglota, y los LLMs trabajan con datos de entrenamiento que preceden las últimas funcionalidades. Cuando le das a un agente de IA la capacidad de buscar los docs actuales, deja de adivinar y empieza a ser útil.

Tres comandos, cero pestañas del navegador

La CLI es refrescantemente simple:

Listar todos los docs

aspire docs list

Devuelve cada página de documentación disponible en aspire.dev. ¿Necesitás salida legible por máquina? Agregá --format Json.

Buscar un tema

aspire docs search "redis"

Busca tanto en títulos como en contenido con puntuación de relevancia ponderada. El mismo motor de búsqueda que alimenta la herramienta de documentación internamente. Obtenés resultados rankeados con títulos, slugs y puntuaciones de relevancia.

Leer una página completa (o solo una sección)

aspire docs get redis-integration

Transmite la página completa como markdown a tu terminal. ¿Necesitás solo una sección?

aspire docs get redis-integration --section "Add Redis resource"

Precisión quirúrgica. Sin hacer scroll por 500 líneas. Solo la parte que necesitás.

El ángulo del agente de IA

Acá es donde se pone interesante para los que desarrollamos con herramientas de IA. Los mismos comandos de aspire docs funcionan como herramientas para agentes de IA — a través de skills, servidores MCP, o wrappers simples de CLI.

En vez de que tu asistente de IA invente APIs de Aspire basándose en datos de entrenamiento obsoletos, puede llamar a aspire docs search "postgres", encontrar los docs oficiales de integración, leer la página correcta, y darte el enfoque documentado. Documentación en tiempo real y actual — no lo que el modelo memorizó hace seis meses.

La arquitectura detrás de esto es intencional. El equipo de Aspire construyó servicios reutilizables (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) en lugar de una integración única. Eso significa que el mismo motor de búsqueda funciona para humanos en la terminal, agentes de IA en tu editor, y automatización en tu pipeline de CI.

Escenarios del mundo real

Consultas rápidas en terminal: Estás tres archivos adentro y necesitás los parámetros de configuración de Redis. Dos comandos, noventa segundos, de vuelta al trabajo:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Desarrollo asistido por IA: Tu skill de VS Code envuelve los comandos de la CLI. Preguntás “Agregá una base de datos PostgreSQL a mi AppHost” y el agente busca los docs reales antes de responder. Sin alucinaciones.

Validación en CI/CD: Tu pipeline valida configuraciones de AppHost contra documentación oficial de forma programática. La salida --format Json se conecta limpiamente con jq y otras herramientas.

Bases de conocimiento personalizadas: ¿Estás construyendo tu propia herramienta de IA? Enviá la salida JSON estructurada directamente a tu base de conocimiento:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Sin web scraping. Sin API keys. Los mismos datos estructurados que usa internamente la herramienta de documentación.

La documentación siempre está actualizada

Esta es la parte que más aprecio. La CLI no descarga una captura estática — consulta aspire.dev con caché basado en ETag. En el momento en que los docs se actualizan, tu CLI y cualquier skill construido sobre ella lo refleja. Sin copias obsoletas, sin momentos de “pero el wiki decía…”.

Para cerrar

aspire docs es una de esas funcionalidades pequeñas que resuelve un problema real de forma limpia. Los humanos obtienen acceso a documentación nativa de terminal. Los agentes de IA obtienen una forma de dejar de adivinar y empezar a referenciar docs reales. Y todo está respaldado por la misma fuente de verdad.

Si estás construyendo con .NET Aspire y todavía no probaste la CLI, ejecutá aspire docs search "tu-tema-aquí" y fijate cómo se siente. Después considerá envolver esos comandos en cualquier skill de IA o configuración de automatización que estés usando — tus agentes te lo van a agradecer.

Mirá el análisis profundo de David Pine sobre cómo se armó la herramienta de documentación, y la referencia oficial de la CLI para todos los detalles.

Cli | The .NET Blog

dotnet new WinUI: Crea apps de Windows sin tocar Visual Studio

Empezar en tres comandos

Qué incluye

Por qué importa para desarrolladores que no usan Visual Studio

Cosmos DB Shell Está en Vista Previa Pública — Y Tiene un Servidor MCP Integrado

Qué lo Hace Diferente de Otras CLIs de Base de Datos

La Base de Código Abierto Importa

Tres Escenarios que Se Vuelven Más Fáciles

Para Empezar

Windows App Dev CLI v0.3: F5 desde la terminal y automatización de UI para agentes

winapp run: F5 desde cualquier sitio

Nuevo paquete NuGet: dotnet run para apps empaquetadas

winapp ui: UI Automation desde la línea de comandos

Otras novedades

Cómo obtenerlo

Deja de vigilar tu terminal: el modo desacoplado de Aspire cambia el flujo de trabajo

Modo desacoplado: un comando, terminal de vuelta

Gestionando lo que está en ejecución

Combínalo con el modo aislado

Por qué esto es enorme para los agentes de código

Para cerrar

azd update — Un solo comando para gobernar todos tus gestores de paquetes

Cómo funciona

El pequeño detalle

Por qué importa

.NET Aspire 13.2 Quiere Ser el Mejor Amigo de Tu Agente de IA

El problema es real

Aspire como infraestructura para agentes

La analogía de los parachoques de boliche

Primeros pasos

Para cerrar

El Modo Aislado de Aspire Resuelve la Pesadilla de Conflictos de Puertos en Desarrollo Paralelo

La solución: --isolated

Escenarios reales donde esto brilla

Cómo funciona internamente

Cuándo usarlo

Para cerrar

Aspire 13.2 incluye una CLI de documentación — y tu agente de IA también puede usarla

El problema que esto realmente resuelve

Tres comandos, cero pestañas del navegador

Listar todos los docs

Buscar un tema

Leer una página completa (o solo una sección)

El ángulo del agente de IA

Escenarios del mundo real

La documentación siempre está actualizada

Para cerrar

La solución: `--isolated`