Aspire | The .NET Blog

Endpoints Privados, VNets, NSGs — Aspire Gestiona la Red Ahora

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

He visto este escenario demasiadas veces. La aplicación está lista. La demo es excelente. Luego aparece la lista de verificación de seguridad: saca el almacenamiento de internet público, ejecuta dentro de una VNet, proporciona IPs de salida para la lista de autorización del socio, demuestra que solo las subredes correctas hablan con los servicios correctos.

En ese punto el modelo de aplicación y el modelo de infraestructura comienzan a divergir de maneras que son dolorosas de mantener.

El nuevo soporte de redes empresariales de Azure para Aspire aborda esto directamente. Describes la forma de la red junto a los recursos que la usan, en tu AppHost.

Los Bloques de Construcción

Aquí está para qué sirve cada concepto de red de Azure, resumido:

Característica	Úsala cuando	Por qué importa
Red virtual	Necesitas un espacio de direcciones privado	El límite de red para subredes, endpoints privados y enrutamiento
Subred	Necesitas separar cargas de trabajo dentro de la VNet	Cada parte del sistema obtiene su propio rango de direcciones y superficie de política
Subred delegada	Un servicio de plataforma (como ACA) necesita gestionar una subred	Permite que el servicio coloque infraestructura gestionada en tu VNet de forma segura
Puerta de enlace NAT	Necesitas IPs públicas de salida predecibles	Dirección estable para listas de autorización y auditoría
Endpoint privado	Quieres un recurso PaaS accesible privadamente	Pone una IP privada para ese servicio dentro de tu VNet, elimina la exposición pública
NSG	Necesitas reglas de tráfico a nivel de subred	Permitir/denegar explícito para tráfico entrante y saliente por subred

Describiéndolo en tu AppHost

El cambio clave aquí es que estás modelando la red junto a los recursos que la usan, no en un archivo Bicep separado que se aleja del modelo de aplicación con el tiempo.

Desde el AppHost, puedes:

Crear VNets y subredes con AddVirtualNetwork() y AddSubnet()
Adjuntar una puerta de enlace NAT a subredes para IPs de salida estables
Crear endpoints privados para almacenamiento, Key Vault, SQL y otros servicios PaaS
Definir NSGs con reglas de seguridad de entrada y salida
Configurar Perímetros de Seguridad de Red para políticas entre recursos

El resultado es que cuando ejecutas azd up, la infraestructura coincide con lo que el modelo de aplicación dice que necesita. No lo que dice una plantilla mantenida manualmente.

Por Qué Importa para Aplicaciones Reales

Algunas cosas que se vuelven significativamente más fáciles una vez que la red se modela en Aspire:

Endpoints privados para Key Vault y almacenamiento — describes WithPrivateEndpoint() en esos recursos, y Aspire maneja la configuración de zonas DNS y el adjunto de endpoints. La aplicación nunca cambia.

IPs de salida consistentes — agrega una puerta de enlace NAT a la subred relevante y cada solicitud de salida de tu aplicación pasa por una IP conocida y estable. Los socios pueden autorizarla. Los auditores pueden rastrearla.

Reglas NSG desde el código — en lugar de hacer clic en el portal o mantener un fragmento de Bicep, tus reglas de seguridad viven en el AppHost junto a los recursos que protegen.

Este es el tipo de integración que no hace que las demos sean emocionantes pero hace que los sistemas de producción sean mantenibles.

Conclusión

La seguridad de red apareciendo tarde en el ciclo de vida del proyecto es un problema resuelto si la modelas junto con la aplicación desde el principio. El soporte de redes empresariales de Aspire hace eso posible sin requerir un seguimiento de infraestructura separado.

Detalles completos en la publicación original: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Soporte de Kubernetes, Registros del Navegador y la Habilidad Aspireify

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Cinco semanas no es mucho tiempo para una versión, pero Aspire 13.3 no lo parece. Los elementos principales son significativos: despliegue de Kubernetes y AKS de primera clase con Helm, una habilidad de incorporación asistida por agente llamada Aspireify, captura de registros del navegador directamente en el dashboard y resultados de comandos estructurados. Además, 45 nuevas características, 134 mejoras y 93 correcciones de errores.

Vamos a los puntos destacados.

Aspireify: Incorporación Asistida por Agente

Agregar Aspire a un proyecto existente suena simple — coloca un AppHost, listo. En la práctica implica mucha arqueología: qué puertos importan, qué variables de entorno son dependencias reales, qué servicios de Docker Compose deben mapearse a integraciones de Aspire.

La nueva habilidad Aspireify le da a tu agente de código un flujo de trabajo guiado exactamente para esto. Cuando aspire init crea un AppHost esqueleto, la habilidad Aspireify ayuda al agente a inspeccionar el repositorio, entender cómo ya funciona y conectar el AppHost para adaptarse a la aplicación — no al revés.

La postura predeterminada es “minimizar los cambios en tu código.” Si tu aplicación ya lee DATABASE_URL, el agente lo mapea con WithEnvironment() en lugar de pedirte que reescribas tu configuración. Si un puerto está codificado de forma fija, la habilidad le indica al agente cuándo preservarlo.

Este es el tipo de herramientas de IA que realmente ahorran tiempo en lugar de generar más trabajo por revisar.

Despliegue de Kubernetes y AKS de Primera Clase

Esta es una que ha estado en la lista de deseos durante un tiempo. Aspire 13.3 incluye soporte de despliegue de Kubernetes y AKS de primera clase con Helm. Ahora puedes apuntar a AKS como destino de despliegue directamente desde las herramientas de Aspire.

Para los equipos que ya ejecutan cargas de trabajo de producción en AKS, esto cierra una brecha significativa. Tu modelo de aplicación de Aspire ahora tiene un camino limpio desde el desarrollo local hasta Kubernetes sin necesidad de escribir manualmente gráficos Helm.

Registros del Navegador en el Dashboard

Esta es una de esas características que parecen pequeñas hasta que estás depurando un problema de frontend.

La nueva API WithBrowserLogs() adjunta un recurso de navegador rastreado a cualquier recurso capaz de endpoints. Aspire lanza Chromium usando un pipe CDP privado y transmite registros de consola, solicitudes de red y errores directamente al flujo de registros del recurso:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

El AppHost de TypeScript admite lo mismo:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Errores de consola, solicitudes de red fallidas, excepciones del lado del cliente — todo visible en el mismo dashboard donde ya estás observando trazas y métricas. Sin necesidad de cambiar de pestaña a las DevTools del navegador para las cosas básicas.

Resultados de Comandos Estructurados

Los comandos de recursos recibieron una mejora significativa. Hasta ahora, los comandos devolvían éxito/fracaso. Ahora devuelven resultados estructurados: texto, JSON o markdown que fluye a través del modelo, la interfaz del dashboard, la CLI y las herramientas MCP.

El dashboard une todo esto con un nuevo centro de notificaciones en el encabezado. Los resultados de los comandos aparecen como notificaciones con marca de tiempo con renderización de markdown y una acción “Ver respuesta”.

Esto hace que los comandos de recursos sean verdaderamente componibles. Una integración ahora puede exponer un comando que devuelve una salida significativa — como una URL de túnel — en lugar de simplemente cambiar el estado en algún lugar.

Conclusión

Aspire 13.3 vale la actualización aunque sea solo por el soporte de Kubernetes. Los registros del navegador y los resultados de comandos estructurados parecen el tipo de mejoras de calidad de vida que se acumulan rápidamente en el flujo de trabajo de desarrollo cotidiano.

Notas de versión completas: What’s New in Aspire 13.3

Aspire 13.2: Soporte para Bun, Mejores Contenedores y Menos Fricción en el Debug

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

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

Si llevas tiempo construyendo backends .NET con frontends JavaScript en Aspire, la versión 13.2 es el tipo de actualización que mejora tu día sin anunciar grandes cambios. Sin nuevos paradigmas llamativos. Solo mejoras sólidas a cosas que eran levemente molestas.

Bun es Ahora Ciudadano de Primera Clase

La característica principal: soporte para Bun en apps Vite. Una llamada fluida, listo.

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

Si tu equipo ya usa Bun — con sus tiempos de instalación dramáticamente más rápidos — Aspire ya no te hace pelear contra la corriente.

Yarn es Más Confiable

Los usuarios de Yarn reciben algo igualmente importante: menos fallos misteriosos. Aspire 13.2 mejora la fiabilidad de withYarn() con addViteApp().

Mejoras en Contenedores

Pull Policy Explícita

const worker = await builder.addContainer("worker", "myorg/worker:latest")
 .withImagePullPolicy(ImagePullPolicy.Never);

Perfecto para flujos donde construyes imágenes localmente y quieres que Compose use exactamente esa sin ir al registry.

PostgreSQL 18+ Funciona Correctamente

PostgreSQL 18 cambió su estructura interna de directorios, lo que rompía silenciosamente el mapeo de volúmenes. Aspire 13.2 lo corrige.

Mejoras de Depuración

DebuggerDisplayAttribute en tipos core — valores útiles en el debugger en lugar de árboles de objetos
Mensajes de error más claros para WaitFor
BeforeResourceStartedEvent se dispara en el momento correcto

Resumiendo

Aspire 13.2 es una versión de calidad enfocada. Vale la pena actualizar, especialmente si usas PostgreSQL 18 con volúmenes de datos.

Post original de David Pine: Aspire 13.2: Bun Support and Container Enhancements.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 se celebra el 18 de abril de 2026 en Kinépolis Diversia en Alcobendas, Madrid. Es el mayor evento de la comunidad Azure en España, reuniendo a 38 ponentes en 3 tracks paralelos que cubren agentes de IA, networking en Azure, Cosmos DB, Fabric, IoT, seguridad y mucho más.

El evento transcurre de 08:30 a 18:30 e incluye keynote, pausas para café, almuerzo y una sesión de cierre con preguntas.

Puntos destacados de la agenda

Domando Agentes de IA: gobernanza, herramientas y APIs con Azure AI Foundry y Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: sistemas multi-agente en acción
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Entradas

La inscripción es una donación simbólica — el precio completo de la entrada se destina directamente a Plan International, apoyando los derechos de los niños y la igualdad en todo el mundo. Aforo limitado, así que reserva tu plaza pronto.

Azure Tour 2026

Además de Madrid, el Global Azure Tour 2026 también incluye paradas en Zaragoza, Tenerife y Sevilla.

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.

.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.

El Dashboard de Aspire 13.2 ahora tiene una API de telemetría — y lo cambia todo

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

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

Si has estado construyendo aplicaciones distribuidas con .NET Aspire, ya sabes que el dashboard es lo mejor de toda la experiencia. Todas tus trazas, logs y métricas en un solo lugar — sin Jaeger externo, sin configuración de Seq, sin momentos de “déjame revisar la otra terminal”.

Aspire 13.2 acaba de mejorar todo significativamente. James Newton-King anunció la actualización, y honestamente, las funciones de exportación de telemetría y la API por sí solas justifican la actualización.

Exportar telemetría como una persona normal

Este es el escenario que todos hemos vivido: estás depurando un problema distribuido, finalmente lo reproduces después de veinte minutos de configuración, y ahora necesitas compartir lo que pasó con tu equipo. ¿Antes? Capturas de pantalla. Copiar y pegar IDs de trazas. El desastre de siempre.

Aspire 13.2 añade un diálogo de Gestión de logs y telemetría donde puedes:

Limpiar toda la telemetría (útil antes de reproducir un bug)
Exportar telemetría seleccionada a un archivo ZIP en formato estándar OTLP/JSON
Re-importar ese ZIP en cualquier dashboard de Aspire después

Esa última parte es la función estrella. Reproduces un bug, exportas la telemetría, la adjuntas a tu work item, y tu compañero puede importarla en su propio dashboard para ver exactamente lo que tú viste. No más “¿puedes reproducirlo en tu máquina?”

Las trazas, spans y logs individuales también tienen una opción “Export JSON” en sus menús contextuales. ¿Necesitas compartir una traza específica? Clic derecho, copiar JSON, pegar en la descripción de tu PR. Listo.

La API de telemetría es el verdadero cambio de juego

Esto es lo que más me emociona. El dashboard ahora expone una API HTTP bajo /api/telemetry para consultar datos de telemetría programáticamente. Endpoints disponibles:

GET /api/telemetry/resources — listar recursos con telemetría
GET /api/telemetry/spans — consultar spans con filtros
GET /api/telemetry/logs — consultar logs con filtros
GET /api/telemetry/traces — listar trazas
GET /api/telemetry/traces/{traceId} — obtener todos los spans de una traza

Todo vuelve en formato OTLP JSON. Esto potencia los nuevos comandos aspire agent mcp y aspire otel del CLI, pero la implicación real es mayor: ahora puedes construir herramientas, scripts e integraciones con agentes IA que consulten la telemetría de tu app directamente.

Imagina un agente de IA que pueda ver tus trazas distribuidas reales mientras depuras. Eso ya no es hipotético — es lo que esta API permite.

La telemetría de GenAI se vuelve práctica

Si estás construyendo apps con IA usando Semantic Kernel o Microsoft.Extensions.AI, apreciarás el visualizador de telemetría GenAI mejorado. Aspire 13.2 añade:

Descripciones de herramientas IA renderizadas como Markdown
Un botón dedicado de GenAI en la página de trazas para acceso rápido
Mejor manejo de errores para JSON de GenAI truncado o no estándar
Navegación click-to-highlight entre definiciones de herramientas

El post menciona que VS Code Copilot chat, Copilot CLI y OpenCode soportan configurar un OTEL_EXPORTER_OTLP_ENDPOINT. Apúntalos al dashboard de Aspire y literalmente puedes ver a tus agentes IA pensar en tiempo real a través de la telemetría. Esa es una experiencia de depuración que no encontrarás en ningún otro lado.

Para cerrar

Aspire 13.2 transforma el dashboard de “bonita UI de depuración” a “plataforma de observabilidad programable”. El flujo de exportación/importación por sí solo ahorra tiempo real en depuración distribuida, y la API de telemetría abre la puerta al diagnóstico asistido por IA.

Si ya estás en Aspire, actualiza. Si no — esta es una buena razón para echarle un vistazo a aspire.dev.

Aspire | The .NET Blog

Endpoints Privados, VNets, NSGs — Aspire Gestiona la Red Ahora

Los Bloques de Construcción

Describiéndolo en tu AppHost

Por Qué Importa para Aplicaciones Reales

Conclusión

Aspire 13.3: Soporte de Kubernetes, Registros del Navegador y la Habilidad Aspireify

Aspireify: Incorporación Asistida por Agente

Despliegue de Kubernetes y AKS de Primera Clase

Registros del Navegador en el Dashboard

Resultados de Comandos Estructurados

Conclusión

Aspire 13.2: Soporte para Bun, Mejores Contenedores y Menos Fricción en el Debug

Bun es Ahora Ciudadano de Primera Clase

Yarn es Más Confiable

Mejoras en Contenedores

Pull Policy Explícita

PostgreSQL 18+ Funciona Correctamente

Mejoras de Depuración

Resumiendo

Global Azure Spain 2026

Puntos destacados de la agenda

Entradas

Azure Tour 2026

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

.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

El Dashboard de Aspire 13.2 ahora tiene una API de telemetría — y lo cambia todo

Exportar telemetría como una persona normal

La API de telemetría es el verdadero cambio de juego

La telemetría de GenAI se vuelve práctica

Para cerrar

La solución: `--isolated`