Dotnet | The .NET Blog

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 se celebra del 11 al 15 de mayo de 2026 en el Barbican Centre de Londres. La conferencia principal de 3 días es de martes a jueves, con talleres opcionales de día completo el lunes y el viernes.

Con 78 sesiones y 14 talleres, es una de las conferencias más completas para desarrolladores en Europa.

Temas

Pensamiento Arquitectónico
Código Funcional en C# 13
Diseño Serverless
IA Semántica
Azure Kubernetes Services
Estrategias Lean DevOps
The Model Context Protocol (MCP)
IA Agéntica en .NET
Refactorizando el Monolito
Programar Más Rápido con LLMs
Criptografía en un Mundo Post-Cuántico
Desarrollo Local First

Ponentes

Elenco de primer nivel incluyendo a Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm y Raju Gandhi.

Entradas e información

El 98% de los asistentes de SDD 2025 calificaron la experiencia general como buena, muy buena o excelente.

Hooks de azd en Python, TypeScript y .NET: adiós a los scripts de shell

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

Si alguna vez has tenido un proyecto completamente en .NET y aun así tuviste que escribir scripts Bash solo para los hooks de azd, conoces bien ese dolor. ¿Por qué cambiar a sintaxis de shell en un paso de pre-provisioning cuando todo lo demás en el proyecto es C#?

Esa frustración tiene solución oficial. La Azure Developer CLI acaba de lanzar soporte multi-lenguaje para hooks, y es exactamente tan bueno como suena.

Hooks, brevemente, por si no los conoces

Los hooks son scripts que se ejecutan en puntos clave del ciclo de vida de azd — antes del provisioning, después del despliegue, y más. Se definen en azure.yaml y permiten inyectar lógica personalizada sin modificar la CLI.

Antes solo se admitían Bash y PowerShell. Ahora puedes usar Python, JavaScript, TypeScript o .NET — y azd se encarga del resto automáticamente.

Cómo funciona la detección

Simplemente apuntas el hook a un archivo y azd infiere el lenguaje por la extensión:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Eso es todo. Sin config adicional. Si la extensión es ambigua, puedes añadir kind: python (o el que corresponda) para especificarlo explícitamente.

Detalles importantes por lenguaje

Python

Coloca un requirements.txt o pyproject.toml junto al script (o en cualquier directorio padre) y azd crea un entorno virtual, instala dependencias y ejecuta el script:

hooks/
├── setup.py
└── requirements.txt

Sin gestión manual de virtualenv. azd busca hacia arriba desde el script el archivo de proyecto más cercano.

JavaScript y TypeScript

El mismo patrón — pon un package.json cerca del script y azd ejecutará npm install primero. Para TypeScript, usa npx tsx sin paso de compilación ni tsconfig.json:

hooks/
├── seed.ts
└── package.json

¿Quieres usar pnpm o yarn? Hay una opción config.packageManager para eso.

.NET

Dos modos disponibles:

Modo proyecto: Si hay un .csproj junto al script, azd ejecuta dotnet restore y dotnet build automáticamente.
Modo single-file: En .NET 10+, puedes poner un archivo .cs independiente y se ejecuta directamente con dotnet run script.cs. Sin archivo de proyecto.

hooks:
 postprovision:
 run: ./hooks/migrate.cs

Si ya estás en .NET 10, el modo single-file es la opción más limpia para scripts simples de migración o seeding. Sin scaffolding, sin .csproj que mantener.

Config por ejecutor

Cada lenguaje soporta un bloque config opcional para ajustar los valores por defecto:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postdeploy:
 run: ./hooks/seed.py
 config:
 virtualEnvName: .venv
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

También puedes mezclar formatos en el mismo bloque hooks: — distintos lenguajes para distintos eventos del ciclo de vida, overrides por plataforma para Windows vs. Linux, lo que necesites.

Por qué importa para desarrolladores .NET

La respuesta aburrida es “consistencia”. Pero en la práctica va más allá. Los hooks eran el último lugar de un proyecto basado en azd que te obligaba a usar otro lenguaje. Ahora todo el pipeline de despliegue — código de app, scripts de infraestructura y hooks del ciclo de vida — puede vivir en un solo lenguaje.

Más concreto: puedes reutilizar tus utilidades .NET existentes en los hooks. ¿Tienes una librería compartida para gestión de esquemas de base de datos? Simplemente referencíala en el proyecto del hook. ¿Tienes un script Python de seeding que ya escribiste? Ponlo directamente en azure.yaml.

Conclusión

Es uno de esos cambios que parecen pequeños pero que eliminan mucha fricción del día a día con azd. El soporte multi-lenguaje para hooks ya está disponible — revisa el post oficial para la documentación completa y el repositorio de azd en GitHub para probarlo en tu próximo proyecto.

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

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.

El clustering de pines por fin llega a .NET MAUI Maps — Una propiedad, cero complicaciones

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

¿Conoces ese momento en el que cargas un mapa con cien pines y todo se convierte en una mancha ilegible? Sí, esa ha sido la experiencia con .NET MAUI Maps hasta ahora. Se acabó.

David Ortinau acaba de anunciar que .NET MAUI 11 Preview 3 trae clustering de pines de serie en Android e iOS/Mac Catalyst. Y lo mejor — es ridículamente fácil de activar.

Una propiedad para gobernarlos a todos

<maps:Map IsClusteringEnabled="True" />

Eso es todo. Los pines cercanos se agrupan en clusters con un badge de cantidad. Haces zoom y se expanden. Alejas y se colapsan. El tipo de comportamiento que los usuarios esperan de cualquier mapa moderno — y ahora lo consigues con una sola propiedad.

Grupos de clustering independientes

Aquí es donde se pone interesante. No todos los pines deberían agruparse juntos. Las cafeterías y los parques son cosas distintas, y tu mapa debería saberlo.

La propiedad ClusteringIdentifier te permite separar pines en grupos independientes:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Los pines con el mismo identificador se agrupan juntos. Identificadores diferentes forman clusters independientes incluso cuando están geográficamente cerca. ¿Sin identificador? Grupo por defecto. Limpio y predecible.

Manejo de taps en clusters

Cuando un usuario toca un cluster, recibes un evento ClusterClicked con todo lo que necesitas:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

Los argumentos del evento te dan Pins (los pines del cluster), Location (el centro geográfico) y Handled (ponlo a true si quieres anular el zoom por defecto). Simple, práctico, exactamente lo que esperarías.

Detalles de plataforma que vale la pena conocer

En Android, el clustering usa un algoritmo personalizado basado en rejilla que recalcula con los cambios de zoom — sin dependencias externas. En iOS y Mac Catalyst, aprovecha el soporte nativo de MKClusterAnnotation de MapKit, lo que significa animaciones suaves y nativas de la plataforma.

Este es uno de esos casos en los que el equipo de MAUI tomó la decisión correcta — apoyarse en la plataforma donde tiene sentido.

Por qué esto importa

El clustering de pines ha sido una de las características más solicitadas en .NET MAUI (issue #11811), y con razón. Todas las apps que muestran ubicaciones en un mapa — seguimiento de envíos, localizadores de tiendas, bienes raíces — lo necesitan. Antes tenías que construirlo tú mismo o recurrir a una librería de terceros. Ahora viene integrado.

Para nosotros los desarrolladores .NET que construimos apps móviles multiplataforma, este es el tipo de mejora de calidad de vida que hace de MAUI una opción genuinamente práctica para escenarios con uso intensivo de mapas.

Empieza ya

Instala .NET 11 Preview 3 y actualiza el workload de .NET MAUI. El ejemplo de Maps incluye una nueva página de Clustering con la que puedes jugar de inmediato.

Ve y construye algo con ello — y deja que tus mapas por fin respiren.

.NET Abril 2026 Servicing — Parches de seguridad que deberías aplicar hoy

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

Las actualizaciones de servicing de abril 2026 para .NET y .NET Framework ya están disponibles, y esta incluye correcciones de seguridad que vas a querer aplicar pronto. Seis CVEs parcheados, incluyendo dos vulnerabilidades de ejecución remota de código (RCE).

Qué se ha parcheado

Aquí va el resumen rápido:

CVE	Tipo	Afecta a
CVE-2026-26171	Omisión de característica de seguridad	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	Ejecución remota de código	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	Ejecución remota de código	.NET 10, 9, 8
CVE-2026-32203	Denegación de servicio	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	Denegación de servicio	.NET Framework 3.0–4.8.1
CVE-2026-32226	Denegación de servicio	.NET Framework 2.0–4.8.1

Los dos CVEs de RCE (CVE-2026-32178 y CVE-2026-33116) afectan al mayor rango de versiones de .NET y deberían ser la prioridad.

Versiones actualizadas

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

Todas están disponibles a través de los canales habituales — dotnet.microsoft.com, imágenes de contenedores en MCR y gestores de paquetes de Linux.

Qué hacer

Actualiza tus proyectos y pipelines de CI/CD a las últimas versiones parcheadas. Si estás corriendo contenedores, descarga las últimas imágenes. Si estás en .NET Framework, revisa las notas de versión de .NET Framework para los parches correspondientes.

Para quienes están corriendo .NET 10 en producción (es la versión actual), 10.0.6 es una actualización obligatoria. Lo mismo para .NET 9.0.15 y .NET 8.0.26 si estás en esas versiones LTS. Dos vulnerabilidades de RCE no son algo que se pospone.

Azure MCP Server 2.0 Acaba de Llegar — La Automatización Agentic en la Nube Auto-Alojada ya Está Aquí

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

Si has estado construyendo algo con MCP y Azure últimamente, probablemente ya sepas que la experiencia local funciona bien. Conecta un servidor MCP, deja que tu agente de IA hable con recursos de Azure, y continúa. Pero en el momento en que necesitas compartir esa configuración entre un equipo? Ahí es donde las cosas se complicaban.

Ya no más. Azure MCP Server acaba de alcanzar 2.0 estable, y la característica principal es exactamente lo que los equipos empresariales han estado pidiendo: soporte para servidor MCP remoto auto-alojado.

¿Qué es Azure MCP Server?

Un repaso rápido. Azure MCP Server implementa la especificación del Protocolo de Contexto del Modelo y expone capacidades de Azure como herramientas estructuradas y detectables que los agentes de IA pueden invocar. Piénsalo como un puente estandarizado entre tu agente y Azure — provisioning, implementación, monitoreo, diagnósticos, todo a través de una interfaz consistente.

Los números hablan por sí solos: 276 herramientas MCP en 57 servicios de Azure. Esa es una cobertura seria.

Lo importante: implementaciones remotas auto-alojadas

Aquí está la cosa. Ejecutar MCP localmente en tu máquina está bien para desarrollo y experimentos. Pero en un escenario de equipo real, necesitas:

Acceso compartido para desarrolladores y sistemas de agentes internos
Configuración centralizada (contexto de tenant, valores predeterminados de suscripción, telemetría)
Límites de red y políticas empresariales
Integración en tuberías CI/CD

Azure MCP Server 2.0 aborda todo esto. Puedes desplegarlo como un servicio interno administrado centralmente con transporte basado en HTTP, autenticación adecuada y gobernanza consistente.

Para autenticación, tienes dos opciones sólidas:

Identidad Administrada — cuando se ejecuta junto a Microsoft Foundry
Flujo On-Behalf-Of (OBO) — delegación de OpenID Connect que llama a APIs de Azure usando el contexto del usuario conectado

Ese flujo OBO es particularmente interesante para nosotros los desarrolladores .NET. Significa que tus flujos de trabajo agentic pueden operar con los permisos reales del usuario, no con alguna cuenta de servicio con excesivos privilegios. Principio de privilegio mínimo, integrado desde el principio.

Endurecimiento de seguridad

Esto no es solo un lanzamiento de características — también es uno de seguridad. El lanzamiento 2.0 añade:

Validación de extremos más fuerte
Protecciones contra patrones de inyección en herramientas orientadas a consultas
Controles de aislamiento más estrictos para entornos de desarrollo

Si vas a exponer MCP como un servicio compartido, estas salvaguardas importan. Mucho.

¿Dónde puedes usarlo?

La historia de compatibilidad con clientes es amplia. Azure MCP Server 2.0 funciona con:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
Agentes CLI: GitHub Copilot CLI, Claude Code
Independiente: servidor local para configuraciones simples
Remoto auto-alojado: la nueva estrella de 2.0

Además hay soporte de nube soberana para Azure US Government y Azure operado por 21Vianet, que es crítico para implementaciones reguladas.

Por qué esto importa para desarrolladores .NET

Si estás construyendo aplicaciones agentic con .NET — ya sea Semantic Kernel, Microsoft Agent Framework, u orquestación propia — Azure MCP Server 2.0 te da una forma lista para producción de dejar que tus agentes interactúen con la infraestructura de Azure. Sin wrappers REST personalizados. Sin patrones de integración específicos del servicio. Solo MCP.

Combinado con la API fluida para MCP Apps que salió hace unos días, el ecosistema .NET MCP está madurando rápidamente.

Empezando

Elige tu ruta:

Repositorio de GitHub — código fuente, documentación, todo
Imagen de Docker — implementación contenedorizada
Extensión de VS Code — integración con IDE
Guía de auto-alojamiento — la característica insignia de 2.0

Resumiendo

Azure MCP Server 2.0 es exactamente el tipo de actualización de infraestructura que no se ve llamativa en una demostración pero lo cambia todo en la práctica. MCP remoto auto-alojado con autenticación adecuada, endurecimiento de seguridad y soporte de nube soberana significa que MCP está listo para equipos reales construyendo flujos de trabajo agentic reales en Azure. Si has estado esperando la señal de “listo para empresas” — esto es.

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

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

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

Conecta tus servidores MCP en Azure Functions a Foundry Agents — Así es como

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

Esto es algo que me encanta del ecosistema MCP: construyes tu servidor una vez y funciona en todas partes. VS Code, Visual Studio, Cursor, ChatGPT — cada cliente MCP puede descubrir y usar tus herramientas. Ahora, Microsoft está añadiendo otro consumidor a esa lista: los agentes de Foundry.

Lily Ma del equipo de Azure SDK publicó una guía práctica sobre cómo conectar servidores MCP desplegados en Azure Functions con agentes de Microsoft Foundry. Si ya tienes un servidor MCP, esto es puro valor agregado — no necesitas reconstruir nada.

Por qué esta combinación tiene sentido

Azure Functions te da infraestructura escalable, autenticación integrada y facturación serverless para alojar servidores MCP. Microsoft Foundry te da agentes de IA que pueden razonar, planificar y tomar acciones. Conectar ambos significa que tus herramientas personalizadas — consultar una base de datos, llamar a una API de negocio, ejecutar lógica de validación — se convierten en capacidades que los agentes de IA empresariales pueden descubrir y usar de forma autónoma.

El punto clave: tu servidor MCP se mantiene igual. Solo estás añadiendo Foundry como otro consumidor. Las mismas herramientas que funcionan en tu configuración de VS Code ahora potencian un agente de IA con el que tu equipo o clientes interactúan.

Opciones de autenticación

Aquí es donde el post realmente aporta valor. Cuatro métodos de autenticación según tu escenario:

Método	Caso de uso
Basado en clave (predeterminado)	Desarrollo o servidores sin autenticación Entra
Microsoft Entra	Producción con identidades administradas
Passthrough de identidad OAuth	Producción donde cada usuario se autentica individualmente
Sin autenticación	Desarrollo/pruebas o solo datos públicos

Para producción, Microsoft Entra con identidad del agente es el camino recomendado. El passthrough de identidad OAuth es para cuando el contexto del usuario importa — el agente pide a los usuarios que inicien sesión, y cada solicitud lleva el token propio del usuario.

Configurándolo

El flujo general:

Despliega tu servidor MCP en Azure Functions — hay ejemplos disponibles para .NET, Python, TypeScript y Java
Habilita la autenticación MCP integrada en tu function app
Obtén tu URL de endpoint — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Añade el servidor MCP como herramienta en Foundry — navega a tu agente en el portal, añade una nueva herramienta MCP, proporciona endpoint y credenciales

Luego pruébalo en el playground de Agent Builder enviando un prompt que active una de tus herramientas.

Mi opinión

La historia de composabilidad aquí se está volviendo realmente fuerte. Construye tu servidor MCP una vez en .NET (o Python, TypeScript, Java), despliégalo en Azure Functions, y cada cliente compatible con MCP puede usarlo — herramientas de programación, apps de chat, y ahora agentes de IA empresariales. Es un patrón de “escribe una vez, usa en todas partes” que realmente funciona.

Para desarrolladores .NET específicamente, la extensión MCP de Azure Functions hace esto sencillo. Defines tus herramientas como Azure Functions, despliegas, y tienes un servidor MCP de nivel producción con toda la seguridad y escalabilidad que Azure Functions proporciona.

Para cerrar

Si tienes herramientas MCP ejecutándose en Azure Functions, conectarlas a agentes de Foundry es una victoria rápida — tus herramientas personalizadas se convierten en capacidades de IA empresarial con autenticación adecuada y sin cambios de código en el servidor.

Lee la guía completa para instrucciones paso a paso sobre cada método de autenticación, y consulta la documentación detallada para configuraciones de producció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

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.

La evaluación de modernización de GitHub Copilot es la mejor herramienta de migración que aún no estás usando

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

Migrar una aplicación legacy de .NET Framework a .NET moderno es una de esas tareas que todos saben que deberían hacer pero nadie quiere empezar. Nunca es solo “cambiar el target framework.” Son APIs que desaparecieron, paquetes que ya no existen, modelos de hosting que funcionan completamente diferente, y un millón de pequeñas decisiones sobre qué containerizar, qué reescribir y qué dejar como está.

Jeffrey Fritz acaba de publicar una inmersión profunda en la evaluación de modernización de GitHub Copilot, y honestamente, es el mejor tooling de migración que he visto para .NET. No por la generación de código — eso ya es estándar. Por el documento de evaluación que produce.

No es solo un motor de sugerencias de código

La extensión de VS Code sigue un modelo de Evaluar → Planificar → Ejecutar. La fase de evaluación analiza todo tu código base y produce un documento estructurado que captura todo: qué necesita cambiar, qué recursos de Azure aprovisionar, qué modelo de despliegue usar. Todo lo posterior — infraestructura como código, containerización, manifiestos de despliegue — fluye de lo que la evaluación encuentra.

La evaluación se almacena en .github/modernize/assessment/ en tu proyecto. Cada ejecución produce un reporte independiente, así que acumulas un historial y puedes rastrear cómo evoluciona tu postura de migración a medida que corriges issues.

Dos formas de empezar

Evaluación Recomendada — el camino rápido. Elige entre dominios curados (Actualización Java/.NET, Cloud Readiness, Seguridad) y obtén resultados significativos sin tocar configuración. Genial para una primera mirada a dónde está tu aplicación.

Evaluación Personalizada — el camino dirigido. Configura exactamente qué analizar: cómputo objetivo (App Service, AKS, Container Apps), SO objetivo, análisis de containerización. Elige múltiples destinos Azure para comparar enfoques de migración lado a lado.

Esa vista de comparación es genuinamente útil. Una app con 3 issues obligatorios para App Service podría tener 7 para AKS. Ver ambos ayuda a decidir el hosting antes de comprometerse con un camino de migración.

El desglose de issues es accionable

Cada issue viene con un nivel de criticidad:

Obligatorio — debe corregirse o la migración falla
Potencial — podría impactar la migración, necesita juicio humano
Opcional — mejoras recomendadas, no bloquean la migración

Y cada issue enlaza a archivos afectados y números de línea, proporciona una descripción detallada de qué está mal y por qué importa para tu plataforma objetivo, da pasos concretos de remediación (no solo “arregla esto”), e incluye enlaces a documentación oficial.

Puedes asignar issues individuales a desarrolladores y tienen todo lo que necesitan para actuar. Esa es la diferencia entre una herramienta que te dice “hay un problema” y una que te dice cómo resolverlo.

Las rutas de actualización cubiertas

Para .NET específicamente:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Cada ruta de actualización tiene reglas de detección que saben qué APIs fueron eliminadas, qué patrones no tienen equivalente directo, y qué issues de seguridad necesitan atención.

Para equipos que gestionan múltiples aplicaciones, también hay un CLI que soporta evaluaciones batch multi-repo — clona todos los repos, evalúalos todos, obtén reportes por app más una vista de portafolio agregada.

Mi opinión

Si estás sentado sobre aplicaciones legacy de .NET Framework (y seamos honestos, la mayoría de los equipos empresariales lo están), esta es la herramienta con la que empezar. Solo el documento de evaluación vale el tiempo — convierte un vago “deberíamos modernizar” en una lista concreta y priorizada de elementos de trabajo con caminos claros hacia adelante.

El flujo de trabajo colaborativo también es inteligente: exporta evaluaciones, compártelas con tu equipo, impórtalas sin re-ejecutar. ¿Revisiones de arquitectura donde los que toman decisiones no son los que ejecutan las herramientas? Cubierto.

Para cerrar

La evaluación de modernización de GitHub Copilot transforma la migración de .NET de un proyecto aterrador e indefinido en un proceso estructurado y rastreable. Empieza con una evaluación recomendada para ver dónde estás, luego usa evaluaciones personalizadas para comparar destinos Azure y construir tu plan de migración.

Lee el walkthrough completo y descarga la extensión de VS Code para probarlo en tu propio código.

Las MCP Apps tienen una API fluida — Construye interfaces ricas para herramientas de IA en .NET en tres pasos

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

Las herramientas MCP son geniales para darle capacidades a los agentes de IA. Pero ¿qué pasa si tu herramienta necesita mostrarle algo al usuario — un dashboard, un formulario, una visualización interactiva? Ahí es donde entran las MCP Apps, y ahora son mucho más fáciles de construir.

Lilian Kasem del equipo de Azure SDK presentó la nueva API de configuración fluida para MCP Apps en Azure Functions con .NET, y es el tipo de mejora en experiencia de desarrollador que te hace preguntarte por qué no fue siempre así de simple.

¿Qué son las MCP Apps?

Las MCP Apps extienden el Model Context Protocol permitiendo que las herramientas lleven sus propias vistas de UI, assets estáticos y controles de seguridad. En lugar de solo devolver texto, tu herramienta MCP puede renderizar experiencias HTML completas — dashboards interactivos, visualizaciones de datos, formularios de configuración — todo invocable por agentes de IA y presentado a los usuarios por clientes MCP.

El problema era que conectar todo esto manualmente requería conocer la especificación MCP a fondo: URIs ui://, tipos MIME especiales, coordinación de metadatos entre herramientas y recursos. No era difícil, pero sí tedioso.

La API fluida en tres pasos

Paso 1: Define tu función. Una herramienta MCP de Azure Functions estándar:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Paso 2: Promuévela a MCP App. En el startup de tu programa:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Paso 3: Añade tu vista HTML. Crea assets/hello-app.html con la interfaz que necesites.

Eso es todo. La API fluida se encarga de toda la plomería del protocolo MCP — genera la función de recurso sintético, establece el tipo MIME correcto e inyecta los metadatos que conectan tu herramienta con su vista.

La superficie de la API está bien diseñada

Algunas cosas que me gustan mucho:

Las fuentes de las vistas son flexibles. Puedes servir HTML desde archivos en disco, o embeber recursos directamente en tu ensamblado para despliegues autónomos:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

El CSP es componible. Explícitamente permites los orígenes que tu app necesita, siguiendo principios de mínimo privilegio. Llama a WithCsp varias veces y los orígenes se acumulan:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Control de visibilidad. Puedes hacer que una herramienta sea visible solo para el LLM, solo para la UI del host, o ambos. ¿Quieres una herramienta que solo renderice UI y no deba ser llamada por el modelo? Fácil:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Primeros pasos

Añade el paquete preview:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Si ya estás construyendo herramientas MCP con Azure Functions, esto es solo una actualización de paquete. El quickstart de MCP Apps es el mejor lugar para empezar si eres nuevo en el concepto.

Para cerrar

Las MCP Apps son uno de los desarrollos más emocionantes en el espacio de herramientas de IA — herramientas que no solo hacen cosas sino que pueden mostrar cosas a los usuarios. La API fluida elimina la complejidad del protocolo y te permite enfocarte en lo que importa: la lógica de tu herramienta y su interfaz.

Lee el post completo para la referencia completa de la API y ejemplos.

C# 15 trae los tipos unión — y son exactamente lo que estábamos pidiendo

Emiliano Montesdeoca — Sun, 05 Apr 2026 00:00:00 +0000

Esta es la que estuve esperando. C# 15 introduce la palabra clave union — uniones discriminadas con coincidencia de patrones exhaustiva impuesta por el compilador. Si alguna vez envidiaste las uniones discriminadas de F# o los enums de Rust, sabés exactamente por qué esto importa.

Bill Wagner publicó el análisis a fondo en el blog de .NET, y sinceramente? El diseño es limpio, práctico y muy C#. Déjame mostrarte qué hay realmente y por qué es más importante de lo que parece a primera vista.

El problema que resuelven las uniones

Antes de C# 15, devolver “uno de varios tipos posibles” desde un método siempre era un compromiso:

object — sin restricciones, sin ayuda del compilador, casting defensivo por todos lados
Interfaces marcadoras — mejor, pero cualquiera puede implementarlas. El compilador nunca puede considerar el conjunto completo
Clases base abstractas — mismo problema, además los tipos necesitan un ancestro común

Ninguna de estas opciones te da lo que realmente querés: un conjunto cerrado de tipos donde el compilador garantiza que manejaste todos los casos. Eso es lo que hacen los tipos unión.

La sintaxis es hermosamente simple

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Una línea. Pet puede contener un Cat, un Dog o un Bird. Las conversiones implícitas se generan automáticamente:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

Y acá está la magia — el compilador impone la coincidencia exhaustiva:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

No se necesita descarte _. El compilador sabe que este switch cubre todos los casos posibles. Si después agregás un cuarto tipo a la unión, cada expresión switch que no lo maneje produce una advertencia. Casos faltantes detectados en tiempo de compilación, no en tiempo de ejecución.

Donde esto se vuelve práctico

El ejemplo de Pet es simpático, pero acá es donde las uniones realmente brillan en código real.

Respuestas de API que devuelven diferentes formas

public union ApiResult<T>(T, ApiError, ValidationFailure);

Ahora cada consumidor está obligado a manejar éxito, error y fallo de validación. No más bugs de “me olvidé de chequear el caso de error”.

Valor único o colección

El patrón OneOrMore<T> muestra cómo las uniones pueden tener un cuerpo con métodos auxiliares:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Los consumidores pasan la forma que les resulte conveniente:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

Componer tipos no relacionados

Esta es la funcionalidad definitiva sobre las jerarquías tradicionales. Podés unir tipos que no tienen nada en común — string y Exception, int e IEnumerable<T>. No se necesita un ancestro común.

Uniones personalizadas para bibliotecas existentes

Acá hay una decisión de diseño inteligente: cualquier clase o struct con un atributo [Union] es reconocida como tipo unión, siempre que siga el patrón básico (constructores públicos para los tipos de caso y una propiedad Value). Bibliotecas como OneOf que ya proveen tipos similares a uniones pueden optar por el soporte del compilador sin reescribir sus internos.

Para escenarios sensibles al rendimiento con tipos de valor, las bibliotecas pueden implementar un patrón de acceso sin boxing con los métodos HasValue y TryGetValue.

El panorama general

Los tipos unión son parte de una historia más amplia de exhaustividad que viene a C#:

Tipos unión — coincidencia exhaustiva sobre un conjunto cerrado de tipos (disponible ahora en preview)
Jerarquías cerradas — el modificador closed previene clases derivadas fuera del assembly que las define (propuesto)
Enums cerrados — previene la creación de valores distintos a los miembros declarados (propuesto)

Juntas, estas tres funcionalidades le darán a C# uno de los sistemas de coincidencia de patrones con seguridad de tipos más completos en cualquier lenguaje mainstream.

Probalo hoy

Los tipos unión están disponibles en .NET 11 Preview 2:

Instalá el SDK de .NET 11 Preview
Apuntá a net11.0 en tu proyecto
Configurá <LangVersion>preview</LangVersion>

Una aclaración: en Preview 2, vas a necesitar declarar UnionAttribute e IUnion en tu proyecto ya que todavía no están en el runtime. Agarrá RuntimePolyfill.cs del repo de docs, o agregá esto:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Para cerrar

Los tipos unión son una de esas funcionalidades que te hacen preguntarte cómo sobrevivimos sin ellas. Coincidencia exhaustiva impuesta por el compilador, sintaxis limpia, soporte genérico e integración con el pattern matching existente — es todo lo que pedimos, hecho a la manera de C#.

Probalos en .NET 11 Preview 2, rompé cosas y compartí tu feedback en GitHub. Esto es preview, y el equipo de C# está escuchando activamente. Tus casos extremos y feedback de diseño van a dar forma a la versión final.

Para la referencia completa del lenguaje, consultá la documentación de tipos unión y la especificación de la funcionalidad.

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

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

Microsoft Agent Framework Llega a 1.0 — Esto Es Lo Que Realmente Importa para Desarrolladores .NET

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

Si has estado siguiendo el camino de Agent Framework desde los primeros días de Semantic Kernel y AutoGen, esto es importante. Microsoft Agent Framework acaba de llegar a la versión 1.0 — listo para producción, APIs estables, compromiso de soporte a largo plazo. Está disponible tanto para .NET como para Python, y está genuinamente preparado para cargas de trabajo reales.

Voy a cortar el ruido del anuncio y centrarme en lo que importa si estás construyendo apps con IA usando .NET.

La versión corta

Agent Framework 1.0 unifica lo que solían ser Semantic Kernel y AutoGen en un único SDK de código abierto. Una abstracción de agente. Un motor de orquestación. Múltiples proveedores de IA. Si has estado saltando entre Semantic Kernel para patrones empresariales y AutoGen para flujos de trabajo multi-agente de nivel investigación, puedes parar. Este es el único SDK ahora.

Empezar es casi injustamente simple

Aquí tienes un agente funcional en .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Eso es todo. Un puñado de líneas y tienes un agente de IA ejecutándose contra Azure Foundry. El equivalente en Python es igual de conciso. Añade herramientas de funciones, conversaciones multi-turno y streaming a medida que avanzas — la superficie de la API escala sin volverse rara.

Orquestación multi-agente — esto va en serio

Los agentes individuales están bien para demos, pero los escenarios de producción generalmente necesitan coordinación. Agent Framework 1.0 viene con patrones de orquestación probados en batalla directamente de Microsoft Research y AutoGen:

Secuencial — los agentes procesan en orden (escritor → revisor → editor)
Concurrente — distribuye a múltiples agentes en paralelo, converge resultados
Handoff — un agente delega a otro basándose en la intención
Chat grupal — múltiples agentes discuten y convergen en una solución
Magentic-One — el patrón multi-agente de nivel investigación de MSR

Todos soportan streaming, checkpointing, aprobaciones con humano en el bucle, y pausa/reanudación. La parte de checkpointing es crucial — los flujos de trabajo de larga duración sobreviven a reinicios de proceso. Para nosotros los desarrolladores .NET que hemos construido flujos de trabajo durables con Azure Functions, esto se siente familiar.

Las funcionalidades que más importan

Aquí va mi lista de lo que vale la pena saber:

Hooks de middleware. ¿Sabes cómo ASP.NET Core tiene pipelines de middleware? Mismo concepto, pero para la ejecución de agentes. Intercepta cada etapa — añade seguridad de contenido, logging, políticas de cumplimiento — sin tocar los prompts del agente. Así es como haces que los agentes estén listos para empresa.

Memoria conectable. Historial conversacional, estado persistente clave-valor, recuperación basada en vectores. Elige tu backend: Foundry Agent Service, Mem0, Redis, Neo4j, o crea el tuyo propio. La memoria es lo que convierte una llamada LLM sin estado en un agente que realmente recuerda el contexto.

Agentes declarativos en YAML. Define las instrucciones de tu agente, herramientas, memoria y topología de orquestación en archivos YAML versionados. Carga y ejecuta con una sola llamada a la API. Esto es un cambio radical para equipos que quieren iterar en el comportamiento del agente sin redesplegar código.

Soporte A2A y MCP. MCP (Model Context Protocol) permite a los agentes descubrir e invocar herramientas externas dinámicamente. A2A (protocolo Agent-to-Agent) habilita la colaboración entre runtimes — tus agentes .NET pueden coordinarse con agentes ejecutándose en otros frameworks. El soporte para A2A 1.0 llegará pronto.

Las funcionalidades en preview que vale la pena seguir

Algunas funcionalidades se lanzaron como preview en 1.0 — funcionales pero las APIs pueden evolucionar:

DevUI — un depurador local basado en navegador para visualizar la ejecución del agente, flujos de mensajes y llamadas a herramientas en tiempo real. Piensa en Application Insights, pero para el razonamiento del agente.
GitHub Copilot SDK y Claude Code SDK — usa Copilot o Claude como un harness de agente directamente desde tu código de orquestación. Compón un agente capaz de programar junto a tus otros agentes en el mismo flujo de trabajo.
Agent Harness — un runtime local personalizable que da a los agentes acceso a shell, sistema de archivos y bucles de mensajería. Piensa en agentes de programación y patrones de automatización.
Skills — paquetes reutilizables de capacidades de dominio que dan a los agentes capacidades estructuradas listas para usar.

Migrando desde Semantic Kernel o AutoGen

Si tienes código existente de Semantic Kernel o AutoGen, hay asistentes de migración dedicados que analizan tu código y generan planes de migración paso a paso. La guía de migración de Semantic Kernel y la guía de migración de AutoGen te guían a través de todo.

Si has estado en los paquetes RC, actualizar a 1.0 es solo un cambio de versión.

Para cerrar

Agent Framework 1.0 es el hito de producción que los equipos empresariales han estado esperando. APIs estables, soporte multi-proveedor, patrones de orquestación que realmente funcionan a escala, y rutas de migración desde tanto Semantic Kernel como AutoGen.

El framework es completamente open source en GitHub, y puedes empezar hoy con dotnet add package Microsoft.Agents.AI. Echa un vistazo a la guía de inicio rápido y los ejemplos para ponerte manos a la obra.

Si has estado esperando la señal de “seguro para usar en producción” — esta es.

azd ahora te permite ejecutar y depurar agentes IA localmente — Esto es lo que cambió en marzo 2026

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

Siete versiones en un mes. Eso es lo que el equipo del Azure Developer CLI (azd) publicó en marzo 2026, y la función estrella es la que estaba esperando: un bucle local de ejecución y depuración para agentes IA.

PC Chan publicó el resumen completo, y aunque hay mucho contenido, déjame filtrarlo a lo que realmente importa para desarrolladores .NET que construyen apps con IA.

Ejecutar y depurar agentes IA sin desplegar

Esta es la grande. La nueva extensión azure.ai.agents añade un conjunto de comandos que te dan una experiencia de bucle interno adecuada para agentes IA:

azd ai agent run — inicia tu agente localmente
azd ai agent invoke — le envía mensajes (local o desplegado)
azd ai agent show — muestra el estado del contenedor y su salud
azd ai agent monitor — transmite logs del contenedor en tiempo real

Antes, probar un agente IA significaba desplegarlo en Microsoft Foundry cada vez que hacías un cambio. Ahora puedes iterar localmente, probar el comportamiento de tu agente, y solo desplegarlo cuando estés listo. Si has estado construyendo agentes con el Microsoft Agent Framework o Semantic Kernel, esto cambia tu flujo de trabajo diario.

El comando invoke funciona tanto contra agentes locales como desplegados, lo que significa que puedes usar el mismo flujo de pruebas sin importar dónde esté corriendo el agente. Ese es el tipo de detalle que te ahorra mantener dos conjuntos de scripts de prueba.

GitHub Copilot configura tu proyecto azd

azd init ahora ofrece una opción “Set up with GitHub Copilot (Preview)”. En lugar de responder prompts manualmente sobre la estructura de tu proyecto, un agente Copilot genera la configuración por ti. Verifica que el directorio de trabajo esté limpio antes de modificar archivos y pide consentimiento de herramientas MCP por adelantado.

Cuando un comando falla, azd ahora ofrece troubleshooting asistido por IA: elige una categoría (explicar, guiar, solucionar o saltar), deja que el agente sugiera una corrección, y reintenta — todo sin salir de la terminal. Para configuraciones de infraestructura complejas, eso ahorra tiempo real.

Container App Jobs y mejoras de despliegue

Algunas funciones de despliegue que vale la pena mencionar:

Container App Jobs: azd ahora despliega Microsoft.App/jobs a través de la configuración existente host: containerapp. Tu plantilla Bicep determina si el destino es un Container App o un Job — sin configuración extra.
Timeouts configurables: Nueva flag --timeout en azd deploy y un campo deployTimeout en azure.yaml. Sin más adivinanzas sobre el límite predeterminado de 1200 segundos.
Fallback de build remoto: Cuando falla el build remoto en ACR, azd hace fallback automático a Docker/Podman local.
Validación preflight local: Los parámetros de Bicep se validan localmente antes de desplegar, detectando parámetros faltantes sin un viaje de ida y vuelta a Azure.

Pulido en la experiencia de desarrollador

Algunas mejoras más pequeñas que se suman:

Detección automática de pnpm/yarn para proyectos JS/TS
Soporte para pyproject.toml para paquetes Python
Directorios de plantillas locales — azd init --template ahora acepta rutas del sistema de archivos para iteración offline
Mejores mensajes de error en modo --no-prompt — todos los valores faltantes reportados de una vez con comandos de resolución
Variables de entorno de build inyectadas en todos los subprocesos de build (.NET, Node.js, Java, Python)

La última es sutil pero importante: tu build .NET ahora tiene acceso a las variables de entorno de azd, lo que significa que puedes hacer inyección de configuración en tiempo de compilación sin scripting adicional.

Para cerrar

El bucle de depuración local de agentes IA es la estrella de esta versión, pero la acumulación de mejoras de despliegue y refinamiento de DX hace que azd se sienta más maduro que nunca. Si estás desplegando apps .NET en Azure — especialmente agentes IA — esta actualización vale la pena.

Revisa las notas completas de la versión para todos los detalles, o comienza con la instalación de azd.

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

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.

La actualización de marzo de Visual Studio te permite crear agentes Copilot personalizados — y find_symbol es clave

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

Visual Studio acaba de recibir su actualización de Copilot más significativa hasta ahora. Mark Downie anunció la versión de marzo, y el titular son los agentes personalizados — pero honestamente, la herramienta find_symbol podría ser la función que más cambie tu flujo de trabajo.

Agentes Copilot personalizados en tu repo

¿Quieres que Copilot siga los estándares de código de tu equipo, ejecute tu pipeline de build, o consulte tus docs internos? Ahora puedes construir exactamente eso.

Los agentes personalizados se definen como archivos .agent.md que colocas en .github/agents/ en tu repositorio. Cada agente tiene acceso completo al workspace, comprensión del código, herramientas, tu modelo preferido, y conexiones MCP a servicios externos.

Agent skills: paquetes de instrucciones reutilizables

Los skills se cargan automáticamente desde .github/skills/ en tu repo o ~/.copilot/skills/ en tu perfil. Piensa en los skills como experiencia modular que puedes mezclar y combinar.

find_symbol: navegación con reconocimiento de lenguaje

La nueva herramienta find_symbol le da al modo agente de Copilot navegación de símbolos basada en servicios de lenguaje. En lugar de buscar texto, el agente puede encontrar todas las referencias a un símbolo, acceder a información de tipos, declaraciones y alcance.

Para desarrolladores .NET, esto es una mejora enorme — las bases de código C# con jerarquías de tipos profundas e interfaces se benefician enormemente.

Perfilar tests con Copilot

Hay un nuevo comando Profile with Copilot en el menú contextual del Test Explorer. Selecciona un test, haz clic en perfilar, y el Profiling Agent lo ejecuta y analiza automáticamente.

Perf tips durante debugging en vivo

La optimización de rendimiento ahora ocurre mientras depuras. Visual Studio muestra tiempo de ejecución y señales de rendimiento inline. ¿Ves una línea lenta? Haz clic en el Perf Tip y pídele a Copilot sugerencias de optimización.

Corregir vulnerabilidades de NuGet desde Solution Explorer

Cuando se detecta una vulnerabilidad en un paquete NuGet, verás un enlace Fix with GitHub Copilot directamente en Solution Explorer.

Para cerrar

Agentes personalizados y skills son el titular, pero find_symbol es la joya oculta — cambia fundamentalmente la precisión de Copilot al refactorizar código .NET. Combinado con profiling en vivo y corrección de vulnerabilidades, esta actualización hace que las funciones de IA de Visual Studio se sientan genuinamente prácticas.

Descarga Visual Studio 2026 Insiders para probarlo todo.

KubeCon Europe 2026: Lo que los desarrolladores .NET deberían saber de verdad

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

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

¿Conoces esa sensación cuando cae un post de anuncios enorme y estás scrolleando pensando “genial, pero qué cambia esto realmente para mí”? Eso me pasa cada temporada de KubeCon.

Microsoft acaba de publicar su resumen completo de KubeCon Europe 2026 — escrito por el mismísimo Brendan Burns — y sinceramente, hay sustancia real aquí. No solo checkboxes de features, sino mejoras operacionales que cambian cómo manejas las cosas en producción.

Te resumo lo que realmente importa para nosotros los desarrolladores .NET.

mTLS sin el impuesto del service mesh

Aquí va la cosa sobre los service meshes: todo el mundo quiere las garantías de seguridad, nadie quiere la carga operacional. AKS por fin está cerrando esa brecha.

Azure Kubernetes Application Network te da TLS mutuo, autorización basada en identidad de aplicación y telemetría de tráfico — sin desplegar un mesh pesado con sidecars. Combinado con Cilium mTLS en Advanced Container Networking Services, tienes comunicación encriptada pod-a-pod usando certificados X.509 y SPIRE para gestión de identidades.

¿Qué significa esto en la práctica? Tus APIs de ASP.NET Core hablando con workers en segundo plano, tus servicios gRPC llamándose entre sí — todo encriptado y verificado a nivel de red, sin cambios en el código de la aplicación. Eso es enorme.

Para equipos migrando desde ingress-nginx, también hay Application Routing con Meshless Istio con soporte completo de Kubernetes Gateway API. Sin sidecars. Basado en estándares. Y lanzaron herramientas ingress2gateway para migración incremental.

Observabilidad de GPU que no es un añadido secundario

Si estás ejecutando inferencia de IA junto a tus servicios .NET (y seamos honestos, ¿quién no está empezando a hacerlo?), probablemente has topado con el punto ciego del monitoreo de GPU. Tenías dashboards geniales de CPU/memoria y luego… nada para GPUs sin configuración manual de exportadores.

AKS ahora expone métricas de GPU nativamente en Prometheus y Grafana gestionados. Mismo stack, mismos dashboards, mismo pipeline de alertas. Sin exportadores custom, sin agentes de terceros.

En el lado de red, añadieron visibilidad por flujo para tráfico HTTP, gRPC y Kafka con una experiencia one-click en Azure Monitor. IPs, puertos, workloads, dirección de flujo, decisiones de políticas — todo en dashboards integrados.

Y aquí viene la que me hizo mirar dos veces: agentic container networking añade una UI web donde puedes hacer preguntas en lenguaje natural sobre el estado de red de tu cluster. “¿Por qué el pod X no llega al servicio Y?” → diagnósticos de solo lectura desde telemetría en vivo. Eso es genuinamente útil a las 2 AM.

Networking cross-cluster que no requiere un doctorado

Multi-cluster en Kubernetes históricamente ha sido una experiencia de “trae tu propio pegamento de red”. Azure Kubernetes Fleet Manager ahora incluye networking cross-cluster mediante Cilium cluster mesh gestionado:

Conectividad unificada entre clusters AKS
Registro global de servicios para descubrimiento cross-cluster
Configuración gestionada centralmente, no repetida por cluster

Si estás corriendo microservicios .NET en varias regiones por resiliencia o cumplimiento, esto reemplaza mucho pegamento custom frágil. El Servicio A en West Europe puede descubrir y llamar al Servicio B en East US a través del mesh, con políticas de routing y seguridad consistentes.

Upgrades que no requieren valentía

Seamos honestos — los upgrades de Kubernetes en producción son estresantes. “Actualizar y rezar” ha sido la estrategia de facto para demasiados equipos, y es la razón principal por la que los clusters se quedan atrás en versiones.

Dos nuevas capacidades cambian esto:

Blue-green agent pool upgrades crean un pool de nodos paralelo con la nueva configuración. Valida el comportamiento, mueve tráfico gradualmente y mantén un camino limpio de rollback. No más mutaciones in-place en nodos de producción.

Agent pool rollback te permite revertir un pool de nodos a su versión anterior de Kubernetes e imagen de nodo después de que un upgrade sale mal — sin reconstruir el cluster.

Juntos, finalmente dan a los operadores control real sobre el ciclo de vida de upgrades. Para equipos .NET, esto importa porque la velocidad de la plataforma controla directamente qué tan rápido puedes adoptar nuevos runtimes, parches de seguridad y capacidades de red.

Los workloads de IA se convierten en ciudadanos de primera clase de Kubernetes

El trabajo upstream en open-source es igualmente importante. Dynamic Resource Allocation (DRA) acaba de llegar a GA en Kubernetes 1.36, haciendo del scheduling de GPU una feature de primera clase en lugar de un workaround.

Algunos proyectos que vale la pena seguir:

Proyecto	Qué hace
AI Runway	API común de Kubernetes para inferencia — despliega modelos sin saber K8s, con descubrimiento en HuggingFace y estimaciones de costo
HolmesGPT	Troubleshooting agéntico para cloud-native — ahora proyecto CNCF Sandbox
Dalec	Builds declarativos de imágenes de contenedor con generación de SBOM — menos CVEs en la etapa de build

La dirección es clara: tu API .NET, tu capa de orquestación con Semantic Kernel y tus workloads de inferencia deberían correr todos en un modelo de plataforma consistente. Estamos llegando ahí.

Por dónde empezaría esta semana

Si estás evaluando estos cambios para tu equipo, esta es mi lista honesta de prioridades:

Observabilidad primero — habilita métricas de GPU y logs de flujo de red en un cluster no-prod. Mira lo que te has estado perdiendo.
Prueba blue-green upgrades — testea el workflow de rollback antes de tu próximo upgrade de cluster en producción. Construye confianza en el proceso.
Pilotea networking con identidad — elige un path de servicio interno y habilita mTLS con Cilium. Mide el overhead (spoiler: es mínimo).
Evalúa Fleet Manager — si corres más de dos clusters, el networking cross-cluster se paga solo en reducción de pegamento custom.

Experimentos pequeños, feedback rápido. Esa es siempre la jugada.

Para cerrar

Los anuncios de KubeCon pueden ser abrumadores, pero esta tanda genuinamente mueve la aguja para equipos .NET en AKS. Mejor seguridad de red sin overhead de mesh, observabilidad real de GPU, upgrades más seguros y bases más fuertes para infraestructura de IA.

Si ya estás en AKS, es un gran momento para ajustar tu baseline operacional. Y si estás planeando mover workloads .NET a Kubernetes — la plataforma acaba de ponerse significativamente más lista para producción.

Foundry Agent Service está en GA: Lo que realmente importa para constructores de agentes .NET

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Seamos honestos — construir un prototipo de agente IA es la parte fácil. La parte difícil es todo lo que viene después: ponerlo en producción con aislamiento de red adecuado, ejecutar evaluaciones que realmente signifiquen algo, manejar requisitos de cumplimiento, y no romper cosas a las 2 AM.

El Foundry Agent Service acaba de llegar a GA, y esta versión está enfocada como un láser en esa brecha del “todo lo que viene después”.

Construido sobre la Responses API

El titular: el Foundry Agent Service de nueva generación está construido sobre la OpenAI Responses API. Si ya estás construyendo con ese protocolo, migrar a Foundry requiere cambios mínimos de código. Lo que ganas: seguridad empresarial, redes privadas, RBAC con Entra, trazabilidad completa y evaluación — sobre tu lógica de agente existente.

La arquitectura es intencionalmente abierta. No estás atado a un proveedor de modelos ni a un framework de orquestación. Usa DeepSeek para planificación, OpenAI para generación, LangGraph para orquestación — el runtime maneja la capa de consistencia.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Redes privadas: el bloqueador empresarial eliminado

Esta es la característica que desbloquea la adopción empresarial. Foundry ahora soporta redes privadas completas de extremo a extremo con BYO VNet:

Sin egress público — el tráfico del agente nunca toca internet público
Inyección de contenedores/subredes en tu red para comunicación local
Conectividad de herramientas incluida — servidores MCP, Azure AI Search, agentes de datos Fabric, todos operan sobre rutas privadas

Ese último punto es crítico. No son solo las llamadas de inferencia las que se mantienen privadas — cada invocación de herramienta y llamada de recuperación también permanece dentro del límite de tu red. Para equipos que operan bajo políticas de clasificación de datos que prohíben el enrutamiento externo, esto era lo que faltaba.

Autenticación MCP hecha correctamente

Las conexiones a servidores MCP ahora soportan el espectro completo de patrones de autenticación:

Método de auth	Cuándo usarlo
Basado en clave	Acceso compartido simple para herramientas internas de toda la organización
Entra Agent Identity	Servicio a servicio; el agente se autentica como él mismo
Entra Managed Identity	Aislamiento por proyecto; sin gestión de credenciales
OAuth Identity Passthrough	Acceso delegado por usuario; el agente actúa en nombre de los usuarios

OAuth Identity Passthrough es el interesante. Cuando los usuarios necesitan dar a un agente acceso a sus datos personales — su OneDrive, su organización de Salesforce, una API SaaS con alcance por usuario — el agente actúa en su nombre con flujos OAuth estándar. Sin identidad de sistema compartida pretendiendo ser todos.

Voice Live: voz a voz sin la fontanería

Agregar voz a un agente solía significar unir STT, LLM y TTS — tres servicios, tres saltos de latencia, tres superficies de facturación, todo sincronizado a mano. Voice Live colapsa eso en una única API administrada con:

Detección semántica de actividad de voz y fin de turno (entiende significado, no solo silencio)
Supresión de ruido y cancelación de eco del lado del servidor
Soporte de interrupción (los usuarios pueden interrumpir a mitad de respuesta)

Las interacciones de voz pasan por el mismo runtime de agente que el texto. Mismos evaluadores, mismas trazas, misma visibilidad de costos. Para soporte al cliente, servicio en campo o escenarios de accesibilidad, esto reemplaza lo que antes requería un pipeline de audio personalizado.

Evaluaciones: de checkbox a monitoreo continuo

Aquí es donde Foundry se pone serio sobre la calidad en producción. El sistema de evaluación ahora tiene tres capas:

Evaluadores incorporados — coherencia, relevancia, fundamentación, calidad de recuperación, seguridad. Conecta a un dataset o tráfico en vivo y obtén puntuaciones.
Evaluadores personalizados — codifica tu propia lógica de negocio, estándares de tono y reglas de cumplimiento específicas del dominio.
Evaluación continua — Foundry muestrea tráfico de producción en vivo, ejecuta tu suite de evaluadores y muestra resultados en dashboards. Configura alertas de Azure Monitor para cuando la fundamentación baje o los umbrales de seguridad se superen.

Todo se publica en Azure Monitor Application Insights. Calidad del agente, salud de la infraestructura, costo y telemetría de la aplicación — todo en un solo lugar.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Seis nuevas regiones para agentes hospedados

Los agentes hospedados ahora están disponibles en East US, North Central US, Sweden Central, Southeast Asia, Japan East y más. Esto importa para requisitos de residencia de datos y para comprimir la latencia cuando tu agente corre cerca de sus fuentes de datos.

Por qué esto importa para desarrolladores .NET

Aunque los ejemplos de código en el anuncio de GA son Python-first, la infraestructura subyacente es agnóstica al lenguaje — y el SDK de .NET para azure-ai-projects sigue los mismos patrones. La Responses API, el framework de evaluación, las redes privadas, la autenticación MCP — todo esto está disponible desde .NET.

Si has estado esperando a que los agentes IA pasen de “demo genial” a “realmente puedo enviar esto al trabajo”, esta versión GA es la señal. Redes privadas, autenticación adecuada, evaluación continua y monitoreo de producción son las piezas que faltaban.

Para cerrar

Foundry Agent Service está disponible ahora. Instala el SDK, abre el portal, y empieza a construir. La guía de inicio rápido te lleva de cero a un agente en ejecución en minutos.

Para el análisis técnico completo con todos los ejemplos de código, revisa el anuncio de GA.

Respuestas en segundo plano en Microsoft Agent Framework: Se acabó la ansiedad por timeouts

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Si has construido algo con modelos de razonamiento como o3 o GPT-5.2, conoces el dolor. Tu agente empieza a pensar en una tarea compleja, el cliente se queda esperando, y en algún punto entre “todo está bien” y “¿se habrá colgado?” tu conexión se corta por timeout. ¿Todo ese trabajo? Perdido.

Microsoft Agent Framework acaba de lanzar respuestas en segundo plano — y honestamente, esta es una de esas funcionalidades que deberían haber existido desde el primer día.

El problema con las llamadas bloqueantes

En un patrón tradicional de petición-respuesta, tu cliente se bloquea hasta que el agente termine. Eso funciona bien para tareas rápidas. Pero cuando le pides a un modelo de razonamiento que haga investigación profunda, análisis de múltiples pasos, o genere un informe de 20 páginas? Estás mirando minutos de tiempo real. Durante esa ventana:

Las conexiones HTTP pueden expirar
Los cortes de red matan toda la operación
Tu usuario se queda mirando un spinner preguntándose si algo está pasando

Las respuestas en segundo plano le dan la vuelta a esto.

Cómo funcionan los tokens de continuación

En lugar de bloquear, lanzas la tarea del agente y recibes un token de continuación. Piénsalo como un ticket de recogida en un taller de reparaciones — no te quedas parado en el mostrador esperando, vuelves cuando está listo.

El flujo es directo:

Envía tu petición con AllowBackgroundResponses = true
Si el agente soporta procesamiento en segundo plano, recibes un token de continuación
Consulta a tu ritmo hasta que el token vuelva null — eso significa que el resultado está listo

Aquí está la versión .NET:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Consultar hasta completar
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Si el agente completa inmediatamente (tareas simples, modelos que no necesitan procesamiento en segundo plano), no se devuelve ningún token de continuación. Tu código simplemente funciona — sin manejo especial necesario.

Streaming con reanudación: la verdadera magia

El polling está bien para escenarios de disparar y olvidar, pero ¿qué pasa cuando quieres progreso en tiempo real? Las respuestas en segundo plano también soportan streaming con reanudación incorporada.

Cada actualización del stream lleva su propio token de continuación. Si tu conexión se cae a mitad del stream, retomas exactamente donde lo dejaste:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simular una interrupción de red
}

// Reanudar desde exactamente donde lo dejamos
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

El agente sigue procesando en el servidor independientemente de lo que pase con tu cliente. Eso es tolerancia a fallos incorporada sin que tú escribas lógica de reintentos o circuit breakers.

Cuándo usar esto realmente

No toda llamada al agente necesita respuestas en segundo plano. Para completaciones rápidas, estás añadiendo complejidad sin razón. Pero aquí es donde brillan:

Tareas de razonamiento complejo — análisis de múltiples pasos, investigación profunda, cualquier cosa que haga a un modelo de razonamiento realmente pensar
Generación de contenido largo — informes detallados, documentos de múltiples partes, análisis extenso
Redes poco fiables — clientes móviles, despliegues en el edge, VPNs corporativas inestables
Patrones UX asíncronos — envía una tarea, ve a hacer otra cosa, vuelve por los resultados

Para nosotros los desarrolladores .NET construyendo apps empresariales, ese último es particularmente interesante. Piensa en una app Blazor donde un usuario solicita un informe complejo — lanzas la tarea del agente, les muestras un indicador de progreso, y les dejas seguir trabajando. Sin gimnasia con WebSockets, sin infraestructura de colas personalizada, solo un token y un bucle de polling.

Para cerrar

Las respuestas en segundo plano están disponibles ahora tanto en .NET como en Python a través de Microsoft Agent Framework. Si estás construyendo agentes que hacen algo más complejo que simple Q&A, vale la pena añadir esto a tu toolkit. El patrón de token de continuación mantiene las cosas simples mientras resuelve un problema de producción muy real.

Revisa la documentación completa para la referencia completa de la API y más ejemplos.

VS Code 1.112: Lo que los desarrolladores .NET realmente deberían importarles

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

VS Code 1.112 acaba de aterrizar, y ¿honestamente? Este pega diferente si pasas tus días en territorio .NET. Hay mucho en las notas de la versión oficial, pero déjame ahorrarte algo de scroll y enfocarme en lo que realmente nos importa.

Copilot CLI se volvió mucho más útil

El gran tema de esta versión es la autonomía del agente — dar a Copilot más espacio para hacer lo suyo sin que tengas que supervisar cada paso.

Direccionamiento y cola de mensajes

¿Conoces ese momento cuando Copilot CLI va a la mitad de una tarea y te das cuenta de que olvidaste mencionar algo? Antes, tenías que esperar. Ahora puedes enviar mensajes mientras una solicitud aún está en progreso — ya sea para dirigir la respuesta actual o encolar instrucciones de seguimiento.

Esto es enorme para esas tareas más largas de scaffolding con dotnet donde estás viendo a Copilot configurar un proyecto y piensas “oh espera, también necesito MassTransit ahí”.

Niveles de permisos

Este es el que más me emociona. Las sesiones de Copilot CLI ahora soportan tres niveles de permisos:

Permisos por defecto — el flujo usual donde las herramientas piden confirmación antes de ejecutarse
Omitir aprobaciones — auto-aprueba todo y reintenta en errores
Autopiloto — totalmente autónomo: aprueba herramientas, responde sus propias preguntas, y sigue hasta que la tarea está completa

Si estás haciendo algo como crear desde cero una nueva API ASP.NET Core con Entity Framework, migraciones, y un setup de Docker — el modo Autopiloto significa que describes lo que quieres y vas por un café. Él lo resolverá.

Puedes habilitar Autopiloto con la configuración chat.autopilot.enabled.

Previsualizar cambios antes de delegar

Cuando delegas una tarea a Copilot CLI, crea un worktree. Antes, si tenías cambios sin commit, tenías que revisar el Control de Código Fuente para ver qué se afectaría. Ahora la vista de Chat muestra los cambios pendientes ahí mismo antes de que decidas si copiarlos, moverlos o ignorarlos.

Algo pequeño, pero te salva de ese momento de “espera, ¿qué tenía en staging?”.

Depura apps web sin salir de VS Code

El navegador integrado ahora soporta depuración completa. Puedes poner breakpoints, hacer step through del código, e inspeccionar variables — todo dentro de VS Code. Se acabó cambiar a Edge DevTools.

Hay un nuevo tipo de depuración editor-browser, y si ya tienes configuraciones de lanzamiento msedge o chrome existentes, migrar es tan simple como cambiar el campo type en tu launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Para desarrolladores de Blazor, esto es un game changer. Ya estás ejecutando dotnet watch en la terminal — ahora tu depuración se queda en la misma ventana también.

El navegador también obtuvo niveles de zoom independientes (por fin), menús de contexto con clic derecho apropiados, y el zoom se recuerda por sitio web.

Sandboxing de servidores MCP

Esto importa más de lo que podrías pensar. Si estás usando servidores MCP — quizás has configurado uno personalizado para tus recursos de Azure o consultas de base de datos — han estado ejecutándose con los mismos permisos que tu proceso de VS Code. Eso significa acceso total a tu sistema de archivos, red, todo.

Ahora puedes ponerlos en sandbox. En tu mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Cuando un servidor en sandbox necesita acceso a algo que no tiene, VS Code te solicita que otorgues permiso. Mucho mejor que el enfoque de “esperar que nadie haga nada raro”.

Descubrimiento de personalizaciones en monorepos

Si trabajas en un monorepo (y seamos honestos, muchas soluciones empresariales .NET terminan siendo uno), esto resuelve un punto de dolor real.

Anteriormente, si abrías una subcarpeta de tu repo, VS Code no encontraba tu copilot-instructions.md, AGENTS.md, o skills personalizados ubicados en la raíz del repositorio. Ahora con la configuración chat.useCustomizationsInParentRepositories, sube hasta la raíz .git y descubre todo.

Esto significa que tu equipo puede compartir instrucciones de agente, archivos de prompt y herramientas personalizadas a través de todos los proyectos en un monorepo sin que todos tengan que abrir la carpeta raíz.

/troubleshoot para depuración de agentes

¿Alguna vez configuraste instrucciones personalizadas o skills y te preguntaste por qué no se están detectando? El nuevo skill /troubleshoot lee los logs de depuración del agente y te dice qué pasó — qué herramientas se usaron o se saltaron, por qué las instrucciones no cargaron, y qué está causando respuestas lentas.

Habilítalo con:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Luego simplemente escribe /troubleshoot why is my custom skill not loading? en el chat.

También puedes exportar e importar estos logs de depuración ahora, lo cual es genial para compartir con tu equipo cuando algo no funciona como se esperaba.

Soporte para archivos de imagen y binarios

Los agentes ahora pueden leer archivos de imagen desde disco y archivos binarios de forma nativa. Los archivos binarios se presentan en formato hexdump, y las salidas de imagen (como capturas de pantalla del navegador integrado) aparecen en una vista de carrusel.

Para desarrolladores .NET, piensa: pega una captura de pantalla de un bug de UI en el chat y haz que el agente entienda qué está mal, o haz que analice la salida del renderizado de un componente Blazor.

Referencias automáticas de símbolos

Pequeña mejora de calidad de vida: cuando copias el nombre de un símbolo (una clase, método, etc.) y lo pegas en el chat, VS Code ahora lo convierte automáticamente en una referencia #sym:Name. Esto le da al agente contexto completo sobre ese símbolo sin que tengas que agregarlo manualmente.

Si quieres texto plano en su lugar, usa Ctrl+Shift+V.

Los plugins ahora se pueden habilitar/deshabilitar

Anteriormente, deshabilitar un servidor MCP o plugin significaba desinstalarlo. Ahora puedes activarlos y desactivarlos — tanto globalmente como por workspace. Clic derecho en la vista de Extensiones o la vista de Personalizaciones y listo.

Los plugins de npm y pypi también pueden auto-actualizarse ahora, aunque pedirán aprobación primero ya que las actualizaciones significan ejecutar código nuevo en tu máquina.

Para cerrar

VS Code 1.112 está claramente empujando fuerte en la experiencia del agente — más autonomía, mejor depuración, seguridad más ajustada. Para desarrolladores .NET, la depuración del navegador integrado y las mejoras de Copilot CLI son las características destacadas.

Si aún no has probado ejecutar una sesión completa de Copilot CLI en modo Autopiloto para un proyecto .NET, esta versión es un buen momento para empezar. Solo recuerda configurar tus permisos y dejarlo cocinar.

Descarga VS Code 1.112 o actualiza desde dentro de VS Code vía Ayuda > Buscar actualizaciones.

Dotnet | The .NET Blog

SDD Conference 2026

Temas

Ponentes

Entradas e información

Hooks de azd en Python, TypeScript y .NET: adiós a los scripts de shell

Hooks, brevemente, por si no los conoces

Cómo funciona la detección

Detalles importantes por lenguaje

Python

JavaScript y TypeScript

.NET

Config por ejecutor

Por qué importa para desarrolladores .NET

Conclusión

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

El clustering de pines por fin llega a .NET MAUI Maps — Una propiedad, cero complicaciones

Una propiedad para gobernarlos a todos

Grupos de clustering independientes

Manejo de taps en clusters

Detalles de plataforma que vale la pena conocer

Por qué esto importa

Empieza ya

.NET Abril 2026 Servicing — Parches de seguridad que deberías aplicar hoy

Qué se ha parcheado

Versiones actualizadas

Qué hacer

Azure MCP Server 2.0 Acaba de Llegar — La Automatización Agentic en la Nube Auto-Alojada ya Está Aquí

¿Qué es Azure MCP Server?

Lo importante: implementaciones remotas auto-alojadas

Endurecimiento de seguridad

¿Dónde puedes usarlo?

Por qué esto importa para desarrolladores .NET

Empezando

Resumiendo

.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

Conecta tus servidores MCP en Azure Functions a Foundry Agents — Así es como

Por qué esta combinación tiene sentido

Opciones de autenticación

Configurándolo

Mi opinión

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

La evaluación de modernización de GitHub Copilot es la mejor herramienta de migración que aún no estás usando

No es solo un motor de sugerencias de código

Dos formas de empezar

El desglose de issues es accionable

Las rutas de actualización cubiertas

Mi opinión

Para cerrar

Las MCP Apps tienen una API fluida — Construye interfaces ricas para herramientas de IA en .NET en tres pasos

¿Qué son las MCP Apps?

La API fluida en tres pasos

La superficie de la API está bien diseñada

Primeros pasos

Para cerrar

C# 15 trae los tipos unión — y son exactamente lo que estábamos pidiendo

El problema que resuelven las uniones

La sintaxis es hermosamente simple

La solución: `--isolated`