Lenguajes de Programación

Qué aportó realmente .NET 9

¿Qué novedades de .NET 9 siguen siendo relevantes? Más que una función aislada, la release introdujo mejoras repartidas entre runtime, bibliotecas, lenguaje y tooling. Para un equipo que mantiene esta versión, interesa distinguir qué cambió realmente de las ventajas genéricas que podrían atribuirse a cualquier actualización de plataforma.

También conviene separar capas. Una optimización del JIT pertenece al runtime; CountBy es una API de LINQ; y las nuevas posibilidades de params corresponden a C# 13. Mezclarlas como si fueran novedades del lenguaje dificulta entender qué dependencia o comportamiento puede verse afectado al actualizar.

Runtime, bibliotecas y mejoras de rendimiento

En el runtime, .NET 9 activó por defecto DATAS, el mecanismo de adaptación dinámica del Garbage Collector al tamaño de la aplicación. Su objetivo es ajustar mejor el heap a la cantidad de datos de larga duración, algo especialmente relevante cuando una aplicación cambia de tamaño o condiciones de ejecución.

El JIT recibió además optimizaciones en loops, inlining y Profile-Guided Optimization, junto con mejoras específicas para Arm64. Esto puede traducirse en mejor ejecución para determinadas cargas de trabajo, pero no existe un porcentaje de mejora aplicable a cualquier aplicación: el impacto depende del código, la arquitectura y el entorno.

Las bibliotecas también incorporaron cambios concretos. System.Text.Json añadió soporte para exportar JSON Schema y trabajar con anotaciones nullable, mientras LINQ estrenó CountBy y AggregateBy, que permiten agregar elementos por clave sin recurrir necesariamente a agrupaciones intermedias con GroupBy.

El valor práctico está en revisar si la aplicación utiliza estas áreas antes de esperar un beneficio. Una actualización del runtime puede mejorar código existente sin modificarlo, mientras que nuevas APIs solo aportan valor si el equipo decide incorporarlas.

C# 13: novedades que siguen siendo relevantes

C# 13 llegó asociado al SDK de .NET 9 y amplió varias capacidades del lenguaje sin romper con su modelo anterior. Entre los cambios más útiles destacan:

• params collections amplía params más allá de los arrays y permite utilizar otros tipos de colección, incluidos Span<T> y ReadOnlySpan<T>.
• El nuevo tipo System.Threading.Lock dispone de semántica específica en la sentencia lock y ofrece una API dedicada para sincronización.
• Los tipos ref struct pueden utilizarse en más escenarios, incluidos determinados genéricos, interfaces y métodos async o iteradores bajo las reglas de seguridad correspondientes.
• Propiedades e indexadores pueden declararse ahora como miembros partial, ampliando las posibilidades de generación y separación de código.

La documentación oficial de C# 13 recoge además otras mejoras de menor impacto general. field, por ejemplo, apareció en C# 13 como característica en preview, por lo que no conviene presentarla como una novedad estable equivalente a las anteriores.

Esta atribución es importante porque características como las expresiones de colección pertenecen a C# 12, y APIs LINQ como MaxBy o Chunk existían antes de .NET 9. Corregir esas mezclas permite valorar C# 13 por sus cambios reales, no por funcionalidades acumuladas del ecosistema.

ASP.NET Core, IA y tooling en .NET 9

.NET 9 también introdujo cambios relevantes fuera del runtime y del lenguaje, especialmente en desarrollo web, herramientas y abstracciones para IA. Aquí conviene aplicar el mismo criterio: seleccionar cambios con impacto práctico y no convertir la release en una suma de productos del ecosistema.

La nomenclatura puede generar cierta confusión: ASP.NET Core conserva Core en su nombre, aunque la plataforma ya se denomina .NET desde .NET 5. Si necesitas ese contexto, la evolución de .NET Core hacia el .NET moderno explica por qué siguen conviviendo estas denominaciones.

ASP.NET Core y Blazor: cambios con impacto práctico

Una de las novedades más visibles fue MapStaticAssets, que añadió un nuevo mecanismo para servir recursos estáticos optimizados. La compilación y publicación pueden preparar compresión, fingerprinting y metadatos de caché, reduciendo parte de la configuración que antes recaía en el servidor o en middleware adicional.

ASP.NET Core 9 incorporó además generación integrada de documentos OpenAPI mediante Microsoft.AspNetCore.OpenApi. Para equipos que mantienen APIs, esto acerca la documentación del contrato al propio framework y facilita integrarla en compilación, pruebas o generación de clientes.

Blazor recibió mejoras orientadas a la experiencia de aplicaciones interactivas, entre ellas una reconexión más clara para escenarios de renderizado en servidor y nuevas APIs para detectar dónde y cómo se representa un componente. También apareció una plantilla que facilita compartir interfaz entre aplicaciones Blazor Web y .NET MAUI Blazor Hybrid.

El interés de estos cambios depende de la arquitectura existente. Una aplicación MVC tradicional puede beneficiarse de MapStaticAssets sin utilizar Blazor, mientras que las mejoras de renderizado solo tienen impacto si el proyecto ya trabaja con ese modelo de componentes.

SDK, testing, IA y EF Core 9

En el SDK, .NET 9 cambió varios comportamientos cotidianos. Terminal Logger pasó a estar habilitado por defecto en los comandos que utilizan MSBuild, y dotnet test mejoró su integración para poder ejecutar en paralelo pruebas del mismo proyecto dirigidas a distintos target frameworks.

También aparecieron los workload sets, que permiten controlar con mayor precisión las versiones de las cargas de trabajo instaladas. Para repositorios grandes, Microsoft introdujo además mejoras en la resolución de dependencias de NuGet, un cambio menos visible pero relevante en tiempos de restore y trabajo con soluciones complejas.

¿Qué incorporó realmente .NET 9 para trabajar con IA? La novedad diferencial no fue la aparición de ML.NET, Semantic Kernel o TorchSharp, que ya existían. Durante el ciclo de .NET 9 se presentaron inicialmente en preview Microsoft.Extensions.AI y Microsoft.Extensions.VectorData, una capa común de abstracciones para trabajar con modelos, embeddings y almacenes vectoriales con menor dependencia de APIs específicas de cada proveedor.

En este bloque también merece una mención breve EF Core 9. La release mejoró especialmente el proveedor de Azure Cosmos DB y avanzó en consultas precompiladas y Native AOT, aunque estas capacidades seguían siendo experimentales y no estaban recomendadas para producción. Antes de valorarlas conviene comprobar qué componentes utiliza realmente el proyecto y qué compatibilidad mantienen al pasar a una versión posterior.

.NET 9 en 2026: cuándo permanecer y cuándo migrar a .NET 10

La situación de soporte cambia la forma de valorar .NET 9. A septiembre de 2026, la versión está en fase Maintenance y finaliza soporte el 10 de noviembre de 2026, mientras .NET 10 es una LTS activa con soporte previsto hasta el 14 de noviembre de 2028.

Eso no significa que cualquier aplicación deba migrarse inmediatamente. La decisión depende del horizonte del proyecto, las dependencias y el riesgo de introducir cambios, pero un sistema que vaya a seguir operativo después del fin de soporte necesita al menos una transición planificada.

Cuándo tiene sentido seguir temporalmente en .NET 9

¿Tiene sentido permanecer en .NET 9? Sí, de forma temporal, cuando existe una razón técnica concreta: una dependencia todavía incompatible, una migración ya programada o un proyecto cuyo ciclo de vida termina antes de que el riesgo de permanecer compense el cambio.

La política oficial de soporte de .NET sitúa actualmente .NET 9 en Maintenance. Durante esta fase sigue recibiendo soporte, pero el margen para posponer una decisión es reducido si la aplicación debe continuar después de noviembre de 2026.

Criterio	Permanecer temporalmente en .NET 9	Planificar migración a .NET 10
Soporte	El proyecto dejará de utilizarse o migrará antes del 10/11/2026	Seguirá en producción después del fin de soporte
Dependencias	Existe un bloqueo identificado y con solución prevista	Paquetes y componentes críticos ya son compatibles
Compatibilidad	El cambio inmediato introduce un riesgo mayor que esperar	Las pruebas permiten validar el salto con margen
Horizonte	Proyecto de vida corta o transición ya calendarizada	Aplicación con mantenimiento y evolución a medio plazo
Recomendación	Mantener con fecha de salida	Preparar la transición

Permanecer no debería equivaler a aplazar la decisión indefinidamente. Si existe un bloqueo, conviene identificar su responsable, impacto y fecha prevista de resolución para evitar que el fin de soporte llegue sin una alternativa validada.

Qué revisar antes de migrar a .NET 10

Pasar de .NET 9 a .NET 10 puede parecer una actualización incremental, pero no debería reducirse a cambiar el TargetFramework. Microsoft documenta cambios incompatibles en áreas como bibliotecas, ASP.NET Core, SDK, serialización, networking, WPF o Windows Forms, y los clasifica según puedan afectar a binarios, código fuente o comportamiento.

Antes de actualizar conviene revisar:

1. Inventariar SDK, runtime y paquetes utilizados por la aplicación y confirmar que las dependencias críticas admiten el nuevo destino.
2. Consultar los breaking changes que afecten a las tecnologías concretas del proyecto, no solo las novedades generales de la release.
3. Ejecutar pruebas funcionales y de integración sobre los flujos críticos y comparar el comportamiento con la versión en producción.
4. Revisar métricas, logs y observabilidad para detectar regresiones de rendimiento o cambios difíciles de identificar solo mediante tests.
5. Preparar un despliegue controlado y definir cómo hacer rollback si aparece un problema después de actualizar.

La decisión final debe combinar soporte y riesgo técnico. Cuanto más tiempo vaya a mantenerse la aplicación después de noviembre de 2026, mayor es el coste de permanecer en una versión sin soporte y más importante resulta completar estas comprobaciones con margen.

SDK, testing, IA y EF Core 9

En el SDK, .NET 9 cambió varios comportamientos cotidianos. Terminal Logger pasó a estar habilitado por defecto en los comandos que utilizan MSBuild, y dotnet test mejoró su integración para poder ejecutar en paralelo pruebas del mismo proyecto dirigidas a distintos target frameworks.

También aparecieron los workload sets, que permiten controlar con mayor precisión las versiones de las cargas de trabajo instaladas. Para repositorios grandes, Microsoft introdujo además mejoras en la resolución de dependencias de NuGet, un cambio menos visible pero relevante en tiempos de restore y trabajo con soluciones complejas.

¿Qué incorporó realmente .NET 9 para trabajar con IA? La novedad diferencial no fue la aparición de ML.NET, Semantic Kernel o TorchSharp, que ya existían. La release presentó, todavía en preview, una capa común de abstracciones mediante Microsoft.Extensions.AI y Microsoft.Extensions.VectorData para interactuar con modelos, embeddings y almacenes vectoriales con menor dependencia de APIs específicas de cada proveedor.

En este bloque también merece una mención breve EF Core 9. La release mejoró especialmente el proveedor de Azure Cosmos DB y avanzó en consultas precompiladas y Native AOT, aunque este último soporte seguía siendo experimental y no estaba recomendado para producción. Antes de valorar estas mejoras conviene comprobar qué componentes utiliza realmente el proyecto y qué compatibilidad mantienen al pasar a una versión posterior.

Conclusiones

.NET 9 aportó mejoras relevantes en runtime, C# 13, ASP.NET Core, tooling y nuevas abstracciones para aplicaciones con IA. Su valor sigue siendo real para entender proyectos construidos sobre esta versión, pero en septiembre de 2026 ya no debe evaluarse como una release en fase de adopción.

Para los equipos que aún la mantienen, la prioridad pasa por revisar soporte, dependencias, compatibilidad y horizonte del proyecto. Permanecer temporalmente puede tener sentido en algunos casos, pero requiere una fecha de salida y una razón técnica concreta.

La transición a .NET 10 debe planificarse con margen, revisando breaking changes, pruebas, observabilidad y rollback. Así, la decisión deja de depender de la novedad de una versión y se convierte en una cuestión de mantenimiento y riesgo técnico.