.NET 10.0.13 o .NET 11 RC2: actualiza sin mezclar carriles

El 13 de octubre de 2026 Microsoft publicó .NET 10.0.13 como actualización de servicio de la línea LTS. El mismo día anunció .NET 11 RC2, la segunda candidata de lanzamiento. Son decisiones distintas: el parche mantiene una versión estable; la candidata sirve para validar la próxima línea en un entorno separado. Que RC2 tenga licencia go-live no la convierte en GA ni en una versión final.

Primero separa las piezas

“Actualizar a .NET 10.0.13” es una frase ambigua. La página de descargas y el anuncio de servicio usan 10.0.13 para el runtime y los componentes de la plataforma de esa actualización. El SDK sigue su propia numeración 10.0.xxx; es la herramienta que restaura, compila y publica. No cambies un SDK 10.0.xxx por una supuesta versión “SDK 10.0.13”.

En un servicio conviene registrar estas capas por separado:

Capa	Carril estable	Carril de laboratorio
SDK de compilación	Un SDK 10.0.xxx fijado por el equipo	El SDK exacto que acompaña a .NET 11 RC2, fijado en el entorno RC
Target framework	net10.0	net11.0, solo en la rama de migración
Runtime y ASP.NET Core	10.0.13, según el instalador o imagen usada	Runtime/ASP.NET Core 11 RC2, sin llamarlo GA
Dependencias	Versiones NuGet revisadas de forma individual	Versiones RC compatibles, una por una

Un paquete NuGet no se actualiza automáticamente porque el runtime tenga otro número. Revisa el archivo de proyecto, el lockfile si existe, la imagen base y el resultado de dotnet --info, dotnet --list-sdks y dotnet --list-runtimes en cada ambiente. Esos comandos son inventario de solo lectura; sus resultados dependen de la máquina o imagen donde se ejecuten.

Carril estable: parchear sin convertirlo en una migración

Para producción, identifica primero si el servicio es framework-dependent, self-contained o una imagen de contenedor. En el primer caso el host aporta el runtime; en el segundo el artefacto lleva el runtime; en el tercero mandan la etiqueta o el digest de las imágenes de SDK y runtime. Actualiza la instalación o imagen que corresponda a 10.0.13, fija un SDK compatible y soportado y mantenlo actualizado según el servicing disponible, de forma independiente del runtime. El parche del runtime no se obtiene instalando una versión inexistente “SDK 10.0.13”; restaura las dependencias que el proyecto ya declara.

Después propone una secuencia pequeña: compilar, ejecutar las pruebas existentes, levantar el servicio en un entorno de validación y revisar salud, logs y rutas críticas. No hace falta subir el target a net11.0 para recibir un parche de net10.0. Tampoco es una razón para actualizar todos los paquetes del archivo de proyecto en el mismo cambio.

Carril RC2: una comparación controlada

Para probar .NET 11 RC2, fija el SDK y el runtime exactos publicados para ese RC: 11.0.100-rc.2.26504.105 y 11.0.0-rc.2.26504.105, respectivamente. No sustituyas esos identificadores por una etiqueta flotante como latest. Usa una rama o checkout separado, una imagen distinta y un entorno efímero o canario. El commit, los datos sintéticos y la configuración no secreta deberían ser comparables, pero nunca copies secretos de producción al laboratorio.

La licencia go-live de una RC permite escenarios de evaluación y producción bajo sus condiciones; sigue siendo una candidata. Mantén un camino de reversión a .NET 10 y espera a una versión GA antes de presentar net11.0 como base final del servicio. No hay en este artículo una medición de latencia, consumo o throughput: la comparación se diseña, no se inventa.

Qué despliegas realmente

El SDK que compila no determina por sí solo el proceso que atenderá tráfico. Antes de comparar resultados, anota el tipo de artefacto y el runtime que ve el proceso:

Forma	Qué lleva el artefacto	Acción para aplicar el parche
Framework-dependent	La aplicación; el host instala el runtime	Actualiza el runtime instalado a 10.0.13 y reinicia el proceso para que lo cargue; actualizar solo el SDK no modifica el proceso publicado.
Self-contained	Aplicación y runtime para el RID elegido	Vuelve a publicar con un SDK compatible y soportado, reemplaza el artefacto que contiene el runtime y reinicia.
Contenedor	Capas de SDK/runtime elegidas en el Dockerfile y su digest	Reconstruye y vuelve a desplegar con la imagen base/runtime fijada, idealmente por digest.

La matriz de prueba debe comparar la misma forma de despliegue en ambos carriles. Un resultado de una ejecución local no demuestra el comportamiento del contenedor ni del servicio administrado por el supervisor.

Qué revisar si la aplicación usa estas rutas

La lista de cambios incompatibles de .NET 11 está marcada por Microsoft como trabajo en progreso. Úsala para seleccionar pruebas por dependencia, no como una afirmación de que todo HTTP o JSON cambió.

Workers y apagado del host

Si el servicio usa BackgroundService, prueba un worker cuyo ExecuteAsync falle de forma controlada. El cambio aplica cuando HostOptions.BackgroundServiceExceptionBehavior es StopHost, que es el valor predeterminado: en .NET 11 fallan IHost.RunAsync y IHost.StopAsync, además de WaitForShutdownAsync y sus equivalentes síncronos, cuando corresponde al flujo de apagado. Comprueba logs, código de salida y reinicio en el entorno de prueba; no conviertas esta observación en una regla para servicios que no hospedan workers.

TLS y certificados AIA

La compatibilidad de SslStream cambia del lado servidor cuando valida certificados de cliente y no se proporciona una X509ChainPolicy personalizada: las descargas AIA están deshabilitadas por defecto. Si se proporciona una política personalizada, se respeta su valor de DisableCertificateDownloads. Si la aplicación depende de esa recuperación, prueba una cadena de certificados de laboratorio y la distribución completa de intermedios. No desactives la validación TLS para “hacer pasar” la prueba y no atribuyas el cambio a todas las conexiones HTTPS.

CBOR, compresión y métricas

Para una aplicación que use CborReader o CborWriter, incluye casos próximos a los límites predeterminados documentados: profundidad 64 para el lector y 1000 para el escritor. La prueba debe comprobar el error esperado al superar el contrato, no relajar el límite a ciegas. Si usa DeflateStream o GZipStream, cubre un payload vacío y uno normal, porque cambian ciertos encabezados o pies de página de payload vacío.

También puede cambiar la forma de exponer métricas HTTP de alta cardinalidad. Verifica solo las métricas que realmente consume la instrumentación del servicio. Estos casos no implican una modificación general de JSON ni de todas las solicitudes HTTP.

Una matriz de prueba que no confunde resultados

La siguiente es una propuesta para que el equipo la ejecute con sus versiones y datos autorizados:

Caso	.NET 10.0.13	.NET 11 RC2	Evidencia que conviene guardar
Arranque y healthcheck	baseline	misma prueba, proceso separado	SDK, runtime, imagen y logs
Worker que falla	si aplica	comparar excepción, apagado y supervisor	código de salida y secuencia temporal
Cadena TLS/AIA	si aplica	misma cadena de laboratorio	certificados, configuración y resultado de validación
CBOR/compresión	si aplica	payloads límite y vacío	bytes o error esperado, sin secretos
Métricas	panel actual	consultas equivalentes	nombres y etiquetas observadas

No compares dos artefactos construidos con SDKs distintos y llames a la diferencia “efecto del runtime”. Registra el proceso que ejecuta la aplicación: un servicio instalado puede usar un runtime distinto del SDK que estuvo presente al compilar, y una imagen puede ocultar esa diferencia si solo se mira el host.

Elige según el riesgo

Para una API estable, el cambio inmediato razonable es adoptar el parche 10.0.13 con la validación habitual y sin saltar de target framework. Para una migración, el siguiente paso es ejecutar la matriz anterior con el SDK/runtime exactos de RC2 y dependencias seleccionadas. Si una ruta sensible falla, corrige o espera a una versión final; no mezcles una solución temporal de RC en el artefacto LTS.

Fuentes oficiales: actualización de servicio de octubre de .NET, descargas y versiones compatibles, anuncio de .NET 11 RC2 y cambios incompatibles de .NET 11.