Auditar qué aplicaciones dependen de .NET 8 y 9 antes de su fin de soporte

Un administrador de sistemas que gestiona unas 200 laptops Windows con Intune ha puesto sobre la mesa una pregunta incómoda: localizar las máquinas con .NET 8 y .NET 9 instalado es sencillo, lo difícil es saber qué aplicaciones dependen realmente de esos runtimes. El fin de soporte, según su calendario, llega en noviembre, y el inventario de runtimes no responde a esa pregunta. Que un equipo tenga el runtime instalado no significa que alguien lo use.

Su plan pasa por desplegar un script de detección en PowerShell a través de Intune y rastrear tres señales: los runtimes y desktop runtimes instalados, los archivos *.runtimeconfig.json que apunten a .NET 8 o 9, y las aplicaciones autocontenidas que llevan su propio coreclr.dll y su runtime dentro del directorio del programa. A eso añade el caso más molesto, el de las aplicaciones de archivo único, donde el runtime va empaquetado dentro del EXE y no aparece en ningún inventario convencional.

Falsos positivos y falsos negativos a la vez

Las tres señales fallan en las dos direcciones. Un equipo puede tener .NET 8 instalado globalmente sin que nada lo necesite ya, y una aplicación de terceros puede traer su propio runtime y no figurar nunca en el listado de runtimes del sistema. El inventario dice qué hay, no qué se ejecuta.

El terreno donde el autor tiene menos confianza es el software de proveedores externos, que es justo donde más cuesta auditar: quien empaqueta decide cómo lo hace y no siempre lo documenta. A eso se suma que un mismo binario puede resolverse contra el runtime global o contra el suyo propio según cómo se desplegó, así que el resultado del script depende de con qué lupa se mire cada endpoint.

Falta la agregación de datos

La segunda mitad del problema no es de detección sino de recolección. El autor reconoce que no tiene resuelto cómo llevar los resultados de cada endpoint a un fichero central para analizar la flota completa en lugar de ir equipo por equipo. Sin eso, un script de detección en Intune sirve para consultar máquinas sueltas, no para planificar una migración ni para decidir a qué proveedor hay que apretar.

La consulta, abierta a otros administradores, no trae respuesta ni herramienta nueva. Pero describe un patrón que se repite con cada ciclo de vida de un runtime: Node, Python y Java han pasado por lo mismo, y la detección de dependencias nunca se resuelve solo con el inventario de paquetes del sistema.

Queda por ver qué enfoques aparecen. La alternativa a auditar el endpoint es partir del inventario de software y de las dependencias declaradas por cada proveedor, lo que asume que las declare y que lo haga con la versión concreta del runtime. Cuando eso no ocurre, la única vía fiable sigue siendo inspeccionar la máquina, y eso no escala a 200 equipos sin una fase de agregación que todavía no existe.