C# Dev Kit 11.0: cómo medir el arranque, la caché y la memoria en VS Code

Microsoft presentó el 6 de octubre de 2026 una arquitectura renovada para C# Dev Kit 11.0. El anuncio la ofrece en el canal pre-release y la ficha de Marketplace puede mostrar una versión distinta del producto; por eso conviene tratarla como una evaluación, no como un cambio que todo equipo deba adoptar.

Hay otra distinción importante: C# Dev Kit es un conjunto de extensiones para Visual Studio Code, mientras que el SDK de .NET 11 es el kit para construir y ejecutar aplicaciones. Microsoft alinea sus números de versión, pero no son el mismo artefacto. Un proyecto puede seguir usando el SDK que requiere su solución mientras se prueba una versión distinta de las herramientas del editor.

Qué cambia en C# Dev Kit

El anuncio de Microsoft atribuye la mejora a varias piezas relacionadas:

• Cada proyecto construye una caché al cargarse. Las aperturas posteriores pueden reutilizarla, de modo que una carga fría y una caliente no representan el mismo trabajo.
• La arquitectura pasa de seis procesos administrados a un servidor interno de C# Dev Kit, CSDevKit, compilado con .NET Native AOT. Esto describe el ejecutable de la extensión; no convierte la aplicación del lector en una aplicación Native AOT.
• Las compilaciones aprovechan fast up-to-date checks y Build Acceleration. La ganancia esperada depende de cuánto cambió la solución; no significa que desaparezcan restauraciones, copias, pruebas o el coste de compilar lo que sí cambió.
• El nuevo editor de MSBuild ofrece ayuda para .csproj, .props y .targets: completados, diagnósticos, navegación, correcciones rápidas y resaltado semántico. También puede mostrar información de paquetes, como versiones nuevas o vulnerabilidades conocidas.
• C# Doctor reúne diagnósticos de entorno, por ejemplo SDK o runtime ausente, target framework no instalado o restauración fallida. Es una guía para investigar, no un escáner completo ni una garantía de que el proyecto compile.

Estas capacidades están en evolución durante el pre-release. Para probarlas, la página de la extensión permite cambiar a Switch to Pre-Release Version; conviene hacerlo en un perfil o rama de trabajo que pueda compararse con el canal estable.

Cómo leer las cifras de Microsoft

Microsoft midió soluciones reales de Orleans y Aspire y separó dos hitos: archivo activo listo, cuando el archivo abierto ya ofrece completado, diagnósticos, navegación y correcciones rápidas; y solución completa lista, cuando terminó la carga general, el descubrimiento de pruebas y la búsqueda de referencias. La siguiente tabla resume una parte de esas mediciones, con la atribución original:

Solución	Proyectos	Archivo activo, 3.3 → 11.0	Solución completa, 3.3 → 11.0
dotnet/orleans	155	hasta 50,3 s → 0,53 s	50,3 s → 2,3 s
dotnet/aspire	407	hasta 84,1 s → 0,47 s	84,1 s → 3,0 s

Son resultados de Microsoft en esos repositorios y su entorno, no mediciones de LBE Tech ni una promesa para cualquier solución. Un equipo puede empezar a editar antes de que estén disponibles todas las referencias y pruebas; anotar ambos instantes evita comparar estados diferentes.

En la misma solución Aspire, Microsoft informó estos tiempos de build:

Cambio	C# Dev Kit 3.3	C# Dev Kit 11.0
Nada	34,4 s	0,88 s
Un archivo C#	36,1 s	2,1 s

La tabla sirve para entender qué comparación propone el anuncio. No es un resultado reproducido: el hardware, el sistema, el estado de la caché, la restauración y la estructura de proyectos pueden cambiar el resultado.

Caché fría, caché caliente y builds

Para una comparación útil, define primero el estado que quieres observar:

• Una carga fría empieza sin la caché de proyectos disponible en el escenario que se está probando.
• Una carga caliente abre de nuevo el mismo estado con la caché ya construida.

La diferencia no implica que exista una caché compartida o que deba incluirse automáticamente en Git. Microsoft menciona que los archivos de caché pueden ayudar a un clon fresco o a un worktree, pero ninguno de los dos demuestra por sí solo que la caché esté ausente: los archivos pueden estar versionados o la máquina puede tener una caché compartida. Para declarar una carga fría, comprueba y registra, antes de abrir la solución, que los archivos de caché de C# Dev Kit no están presentes en ese escenario. Si están versionados, prepara una copia o checkout comparable que los omita mediante un procedimiento reversible y documentado; anota exactamente qué se omitió y conserva el escenario caliente después de construir la caché. No borres artefactos con una operación improvisada ni conviertas esta posibilidad en una política Git universal.

Separa también dos builds ejecutadas desde VS Code con la acción de C# Dev Kit Build Solution sobre la solución completa: una sin cambios y otra después de editar un único archivo C#. Usa la misma acción, versión y configuración en ambos casos. Build Project puede medirse aparte para un proyecto y sus dependencias, pero no es comparable con la tabla de una solución como Aspire. Registra por separado restauración, compilación, copia de salidas, pruebas y arranque de la aplicación. Una ejecución de dotnet build por CLI puede servir como control separado, pero no demuestra por sí sola las optimizaciones de la ruta IDE de C# Dev Kit ni debe mezclarse con ella.

La frontera de la memoria

Microsoft reporta asignaciones del servidor de C# Dev Kit, no de todo el escritorio:

Solución	Proyectos	Archivos C#	C# Dev Kit 3.3 → 11.0
dotnet/orleans	155	4.010	1.307 → 208 MB
dotnet/roslyn	398	18.153	2.000 → 379 MB
dotnet/aspire	407	4.686	2.072 → 316 MB

El propio anuncio excluye el servicio de lenguaje Roslyn y la huella de Visual Studio Code, que permanecen en procesos separados. Por tanto, una cifra del Administrador de tareas para toda la ventana no es comparable con la tabla. En una prueba propia hay que identificar el proceso que C# Dev Kit declara como servidor, explicar cómo se tomó la muestra y mantener la misma frontera en todas las versiones.

Protocolo para medir tu solución

Este es un protocolo de comparación, no un benchmark ya ejecutado:

1. Fija el commit, sistema operativo, CPU y RAM, versión de VS Code, extensión C#, canal de C# Dev Kit, SDK seleccionado por global.json y configuración de build. Conserva esas versiones antes de cada tanda.
2. Describe la solución: número de proyectos, archivos C# y target frameworks. Elige un repositorio representativo; no extrapoles desde una aplicación pequeña a un monorepo.
3. Mide por separado “archivo activo listo” y “solución completa lista”. Declara una tanda fría solo después de comprobar y registrar, antes de abrir la solución, que los archivos de caché de C# Dev Kit están ausentes en ese escenario. Un perfil, clon o worktree nuevo no basta si la caché está versionada o compartida; si está versionada, prepara una copia o checkout comparable que omita esos archivos mediante un procedimiento reversible y documentado, y conserva el escenario caliente después de construir la caché. No borres artefactos con una operación improvisada.
4. Desde VS Code, usa la acción de C# Dev Kit Build Solution sobre la solución completa: una vez sin cambios y otra tras tocar un único archivo C#. Mantén la misma acción, versión y configuración, y registra aparte restore, tests y arranque de la aplicación. Si además mides Build Project, etiquétalo como una medición separada del proyecto y sus dependencias, no como equivalente de la solución completa. Una ejecución de dotnet build por CLI solo es un control separado; no demuestra las optimizaciones de la ruta IDE de C# Dev Kit.
5. Mide el proceso o procesos del servidor de C# Dev Kit y deja fuera Roslyn y VS Code. Anota la herramienta de observación, el instante de la muestra y si el valor es pico o promedio.
6. Repite cada escenario con la misma preparación, conserva los datos brutos y reporta mediana o rango únicamente después de ejecutar la prueba. Este artículo no inventa resultados propios.
7. Si comparas caché versionada, declara los archivos exactos y las condiciones del clon o worktree. Evalúa también invalidación y tamaño antes de recomendar una práctica al equipo.

La conclusión debe ser condicional: una solución grande con esperas de carga o presión de memoria puede justificar la evaluación del pre-release; otra solución puede no obtener una ganancia apreciable o necesitar esperar a una versión estable.

Editor de MSBuild y C# Doctor en una revisión breve

Abre un .csproj, .props o .targets representativo y observa si el editor ofrece completado, diagnóstico y navegación para los elementos que realmente usa tu solución. Después ejecuta C# Doctor y conserva qué comprobaciones identifica: SDK o runtime, target framework, restore y avisos de paquetes. Documenta la versión probada y cualquier falso positivo o limitación; no concluyas que la extensión sustituyó al build ni que C# Doctor cubre toda la seguridad del proyecto.

Requisitos, plataformas y licencia

La ficha oficial de C# Dev Kit en Visual Studio Marketplace lista Windows, macOS, Linux y Codespaces como entornos. En la consulta del 6 de octubre de 2026, su apartado de requisitos lista .NET 10 SDK y señala la instalación automática de la extensión C# y .NET Install Tool. Es un dato de esa ficha y puede cambiar con el canal; no debe sustituirse por “se necesita el SDK de .NET 11”. Comprueba siempre el requisito que aparece en la versión que vas a probar.

La misma ficha indica que el kit es gratuito para individuos, academia y proyectos de código abierto bajo los términos aplicables a Visual Studio Community; para organizaciones, lo incluye Visual Studio Professional/Enterprise y GitHub Codespaces. La documentación de Microsoft Learn explica la elegibilidad. Son condiciones de licencia, no asesoría legal: una organización debe revisar los términos vigentes para su caso.

Decisión práctica

No hay obligación de migrar al SDK de .NET 11 por probar C# Dev Kit 11.0, ni de publicar una aplicación con Native AOT. La decisión debería salir de una comparación reproducible de la solución propia: tiempos de archivo activo y solución completa, cargas frías y calientes, builds con y sin cambios y memoria del servidor de la extensión con la frontera correctamente declarada.

Si el pre-release mejora un cuello de botella concreto sin romper restauración, pruebas, edición MSBuild o diagnóstico, conserva el protocolo y el commit para repetirlo cuando cambie la extensión. Si no mejora, espera otra versión o mantén el canal estable; las tablas de Microsoft son contexto técnico valioso, no sustituto de la evidencia de tu entorno.

Fuentes oficiales

• A faster, lighter C# Dev Kit — .NET Blog
• C# Dev Kit — Visual Studio Marketplace
• C# Dev Kit for Visual Studio Code — Microsoft Learn
• .NET 11 downloads
• The .NET SDK overview