.NET 11 RC1: uniones en C# 15, Blazor agéntico y un salto visible en la velocidad de las herramientas

Anunciada el martes inmediatamente posterior a un fin de semana de tres días, la Release Candidate 1 de .NET 11 llegó con su publicación de lanzamiento y notas detalladas el mismo día. El programa en directo abrió con un ambiente festivo, reprodujo una animación divertida compartida en el chat y prometió una intro aún más vistosa para la RC2. Para mí, la etapa RC es donde terminan los experimentos y comienzan los ensayos de producción, y este programa llevó exactamente esa seriedad.

En el lado de C# 15, los tipos unión fueron la estrella. La demo partió de un código familiar pero defectuoso: varios tipos parecidos a mascotas, sin relación entre sí, transportados como objetos simples porque no comparten ninguna biblioteca. El compilador no puede verificar nada ahí; un tipo que no sea mascota puede colarse silenciosamente en la lista y solo explotar en tiempo de ejecución. La nueva sintaxis de unión convierte ese desorden en un concepto de lenguaje de primera clase.

El nuevo compilador entiende las conversiones implícitas hacia valores unión y verifica las expresiones switch que cubren todos los casos. Una rama faltante ahora aparece como error de compilación en lugar de una sorpresa en tiempo de ejecución. Para bibliotecas existentes que ya se comportan como uniones, existe una vía de escape mediante atributos: los tipos que exponen los miembros que el compilador busca reciben el tratamiento de unión sin adoptar la nueva sintaxis. También noté que la publicación sobre jerarquías cerradas salió en el blog el mismo día.

El segmento de ASP.NET Core se estructuró en torno a seis temas principales: fundamentos más sólidos, seguridad, rendimiento y observabilidad. El equipo dijo haberse centrado en puntos de dolor de larga data procedentes de los comentarios de los usuarios, apuntando a servicios modernos construidos con APIs mínimas y Blazor. Facilitar las configuraciones distribuidas junto con el equipo de Aspire formaba parte de la misma historia.

La noticia más concreta en validación fueron las reglas asíncronas. Las anotaciones de datos clásicas son totalmente síncronas; no había respuesta a nivel de lenguaje para comprobaciones que deban consultar una base de datos o llamar a un servicio. Ahora modelos como los objetos de solicitud de registro y reserva pueden declarar reglas como correo único y nombre de usuario único. El ejemplo de API mínima mostraba estas reglas puestas directamente sobre los tipos de solicitud.

También se consideró la experiencia de usuario: el formulario lee, a través del contexto de edición, si las comprobaciones están pendientes, fallidas o válidas. La demo usaba pequeños componentes personalizados para mostrar esos estados; no forman parte del framework, pero eran sencillos de escribir. A medida que el usuario escribe, las comprobaciones de disponibilidad se ejecutan y la interfaz refleja el estado al instante. Ese detalle, en mi opinión, eleva la validación asíncrona de adorno de demo a algo publicable.

La misma sección escondía una sorpresa de localización: al cambiar el formulario al español, todo se localizó limpiamente, incluidas las reglas asíncronas personalizadas. Los mensajes integrados de campo obligatorio y formato de correo también se localizaron, sin añadir propiedades extra a los atributos. El equipo subrayó que esta simplificación es nueva en la RC1. Cualquiera que publique formularios multilingües respirará más tranquilo.

Casi todas las aplicaciones modernas son distribuidas: un frontend, varios servicios backend, una base de datos, una caché y servicios de IA. Ejecutarlos juntos en local, permitir que se descubran entre sí, cablear la observabilidad de extremo a extremo y entregar el conjunto es un trabajo en sí mismo. El segmento de Aspire del programa apuntaba exactamente a ese dolor. Mantener la misma topología del desarrollo a la producción me pareció la promesa que ahorrará más horas.

Para Blazor WebAssembly se introdujo un paquete de valores predeterminados específico del cliente; las necesidades de configuración de ejecutarse en el navegador viven en su propio proyecto. Una nueva plantilla de proyecto levanta ese esqueleto en una sola búsqueda. Frontend, backend y orquestación quedan entonces lado a lado en la misma solución. La plantilla termina la era de memorizar documentación de configuración.

El modelado ocurre en el proyecto host de la aplicación con un paquete de integración específico de Blazor: el servicio backend se añade como de costumbre, mientras que el proyecto WebAssembly se une a la orquestación como participante de primera clase y declara su dependencia de la API. Gracias a ese modelo, el orquestador sabe qué pieza es la aplicación de navegador y la trata en consecuencia. Unas pocas líneas de declaración se convierten en una seria comodidad en tiempo de ejecución.

La nueva puerta de enlace de Blazor se presentó como un componente de hospedaje listo para producción que actúa como proxy de las solicitudes. Reemplaza al antiguo servidor de desarrollo, de modo que desarrollo y producción comparten la misma historia de hospedaje. Las reglas de descubrimiento de servicios fluyen del cliente al backend sin luchas entre orígenes. Hacer fluir la configuración del backend al frontend también es tarea de la puerta de enlace.

La demo en directo trazó el camino completo a través de una página meteorológica: la aplicación de navegador llamó a la puerta de enlace, la puerta de enlace alcanzó el servicio backend y el descubrimiento se resolvió solo. En el lado del panel, las trazas y métricas de la aplicación, la puerta de enlace y el servicio se fusionaron en una única vista. El viaje de la solicitud, desde el clic en el navegador hasta la respuesta del backend, podía seguirse paso a paso en la vista de trazas. En sistemas distribuidos esa visibilidad es una necesidad, no un lujo.

La sección web agéntica presentó los componentes Blazor AI como una biblioteca experimental. La idea es simple: en lugar de perderse en menús y leer manuales, los usuarios logran cosas hablando con un asistente dentro de la aplicación. Los componentes hacen que tales experiencias de asistente sean baratas de construir. Lo leí como un frontend que aprende a comportarse como una línea de comandos.

El protocolo subyacente, AGUI, fue descrito como el canal entre agentes e interfaces humanas; a diferencia de los protocolos agente-a-agente y de herramientas, su enfoque es la interacción con personas. La aplicación de recetas de la demo mostraba al asistente editando el estado de una receta en tiempo real. El mismo patrón se repitió en tres demos distintas, lo que me dice que el equipo ha convertido este flujo en un hábito.

Las llamadas a herramientas del backend se visualizaron con un ejemplo meteorológico: cuando el usuario preguntó por el clima de Seattle, el asistente invocó la herramienta pertinente, y el bloque correspondiente del historial de conversación fue capturado y renderizado como una tarjeta meteorológica personalizada. La tarjeta que mostraba veinte grados y sol arrancó risas en la sala. La implementación descansaba en un asistente equipado con el paquete de extensiones más un renderizador que empareja bloques en el cliente. El patrón es nítido: cada llamada a herramienta puede convertirse en una pieza de interfaz a medida.

Las llamadas a herramientas del frontend corren sobre el mismo protocolo: una capacidad del lado cliente, como cambiar el color de acento de la interfaz, se anuncia al asistente del lado servidor. En la demo el acento cambió a verde y el frontend se actualizó al instante. La configuración se limita a registrar una acción de interfaz y vigilar los bloques entrantes. Así, la inteligencia del lado servidor llega a una mano del lado cliente.

La mayor pero más silenciosa noticia de MAUI fue el cambio de runtime: dejar atrás el antiguo runtime monolítico por el mismo runtime central que el resto del ecosistema. No es un botón que los usuarios verán; al contrario, pasar desapercibido cuenta como éxito. A cambio, las herramientas estándar de perfilado y trazado funcionan desde el primer momento. Toda inversión futura en herramientas está planificada sobre esta base.

En el lado visible, el equipo atacó años de pequeños cortes de papel acumulados, con un asistente de codificación haciendo el trabajo pesado. La aplicación de agenda del evento en la demo fue generada de extremo a extremo por el asistente; hasta el tablero de misión con temática de cohete, el modo oscuro y el simpático icono de robot fueron ideas suyas. En plena demo, el presentador abrió el editor para mostrar un detalle olvidado y siguió adelante sin teclear una sola línea. El mensaje para todos los que encontraban MAUI intimidante fue claro: ahora es el momento de probarlo.

En el lado de los mapas, el clustering y los iconos personalizados ahora vienen de serie; tareas que antes exigían manejadores personalizados se resuelven con una sola función. Las pantallas de inicio en modo claro y oscuro se simplificaron de manera similar. También se anunció que las expresiones C de ejemplo generadas desde el código se activan por defecto en .NET 11, presentadas como mejoras muy queridas del lenguaje de marcado tras veinte años de silencio. A quien estuviera nervioso con el lenguaje de marcado se le aconsejó dejar que el asistente lo escribiera.

DevFlow, entre las herramientas asistidas por agentes, nació como respuesta al dolor de la automatización que secuestra el cursor: en lugar de hacer capturas de pantalla, adivinar coordenadas de clic y bloquear el ratón del usuario mientras tanto, promete visión e interacción dentro de la aplicación. La implementación se guardará para el programa de la RC2; los anfitriones subrayaron que se reveló aquí primero. Que se le mencionara junto a las herramientas de IA de los labs de MAUI muestra claramente la dirección.

El segmento de SDK y MSBuild explicó por qué el rendimiento importa ahora: más pipelines de integración continua que nunca, bucles de asistentes ejecutándose en paralelo y pequeñas herramientas de línea de comandos invocadas una y otra vez. Cada invocación paga un peaje: arrancar la aplicación, cargar el runtime central e interpretar el comando. Se están usando técnicas de compilación anticipada para recortar ese coste de arranque. La charla enmarcó cómo ha cambiado la relación entre desarrollador y herramientas, con varios árboles de trabajo y asistentes corriendo lado a lado en una misma máquina.

Viene un proceso servidor MSBuild persistente: en lugar del modelo por lotes de una sola solicitud, una estructura que conserva el estado entre compilaciones, comparada con cómo el compilador premoderno reconstruía su universo en cada comando. En una solución de muestra de tres proyectos, el tiempo de compilación sin cambios bajó aproximadamente un tercio. Para las compilaciones multiproceso, el objetivo es compartir en el mismo proceso en lugar de ejecutar cada proyecto en su propio proceso. Mejoras de colaboradores también hicieron deterministas las imágenes de contenedor y más rápidos los envíos al registro, con una contenedorización por línea de comandos visiblemente más veloz.

En el lado de las bibliotecas, el presentador cubrió un espectro desde el microcódigo del JIT hasta analizadores numéricos con dos adiciones: una nueva API de análisis que escanea los separadores en una sola pasada en lugar de recorrerlos dos veces, y cientos de funciones que incluyen sumas aceleradas en trabajos decimales y de coma flotante. Los formatos flotantes hexadecimales, los literales binarios y el soporte de matemática genérica forman un campo demasiado amplio para una demo de diez minutos. El cierre redujo el C# dev kit a un solo proceso: alrededor de una caída de memoria del ochenta y cinco por ciento hasta 243 megabytes, cuatro o cinco instancias en el mismo espacio, arranque de solución acelerado mediante un archivo de caché e inicios rápidos desde un binario compilado nativamente. La publicación anual de rendimiento está cerca, dijeron los anfitriones, y la serie continúa con el programa de la RC2.