Instalaciones de .NET administradas en Windows

Las instalaciones de .NET parcialmente eliminadas son una razón común por la que el software de examen de vulnerabilidades como Administración de vulnerabilidades de Microsoft Defender notificará un dispositivo. Comprender cómo funcionan las instalaciones de .NET puede ayudar a los administradores a investigar informes y a realizar acciones correctivas.

En Windows, .NET componentes como el entorno de ejecución y el SDK constan de varios MSIs. Los MSIs individuales no se distribuyen directamente. En su lugar, se encadenan para crear agrupaciones.

Adquisición de .NET en Windows

• Los paquetes independientes (EXE) se pueden descargar desde el sitio web de .NET.
• WinGet proporciona paquetes que contienen los paquetes de .NET.
• Las actualizaciones de mantenimiento distribuyen los paquetes a través de Microsoft Update mediante actualizaciones automáticas, WSUS y el catálogo de Windows Update.
• Los proveedores de software independientes (ISV) pueden redistribuir .NET paquetes como parte de su software.
• A veces, los OEM incluyen copias preinstaladas de conjuntos de .NET en las imágenes de fábrica de nuevos dispositivos.
• Algunas Azure imágenes de Marketplace de Windows incluyen copias preinstaladas de los conjuntos.
• Los administradores de paquetes de terceros, como Chocolatey, también distribuyen los paquetes de .NET.
• A veces, las empresas vuelven a empaquetar los paquetes mediante paquetes propietarios para la distribución interna.
• Algunos hosts de aplicaciones de .NET también pueden dirigir a los usuarios para descargar e instalar paquetes en tiempo de ejecución que faltan.

Visual Studio también se pueden usar para adquirir .NET y usar los mismos MSIs que los conjuntos independientes.

Note

El paquete del SDK de .NET incluido con Visual Studio hasta la versión 16.2. A partir de .NET Core 3.0 en Visual Studio 16.3, las agrupaciones del SDK se reemplazaron por las INSTANCIAS individuales de .NET MSIs.

Upgrades

.NET admite actualizaciones entre versiones de revisión dentro de una versión principal o secundaria. .NET 8.0.7 actualizará versiones anteriores como 8.0.4 o 8.0.0, incluidas las versiones preliminares, pero no actualizará una versión principal anterior como .NET 7.0. El SDK de .NET admite actualizaciones entre revisiones dentro de una banda de características. El SDK 8.0.100 se puede actualizar a la versión 8.0.103, pero el SDK 8.0.3xx no actualizará las bandas de características 1xx o 2xx.

La mayoría de las actualizaciones se controlan en el nivel de agrupación. La versión anterior solo se quita una vez instalada la nueva versión. Hay dos excepciones: el host de .NET y los MSIs del módulo ASP.NET Core se actualizan en su lugar.

A partir de .NET 8, los usuarios tienen la opción de aplazar la eliminación de la versión anterior de un lote.

Composición de agrupación y recuento de referencias

Las agrupaciones se componen de varios MSIs, algunas de las cuales se comparten entre varias agrupaciones.

• La agrupación en tiempo de ejecución contiene tres MSIs que también se incluyen en el entorno de ejecución de escritorio y los conjuntos de SDK.
• La agrupación de escritorio incluye una MSI adicional que se comparte con la agrupación del SDK.
• El SDK incluye MSIs adicionales que contienen la CLI, las plantillas y los paquetes de destino que se usan para crear y compilar aplicaciones .NET.

Los MSIs compartidos se administran mediante el recuento de referencias. Cada .NET MSI crea una clave del Registro denominada clave de proveedor que permite que una agrupación se registre como dependiente. Si ya está instalado un MSI, la agrupación solo actualiza la información de registro. Las agrupaciones no se registran cuando se quitan. Los MSIs compartidos solo se quitan una vez que no hay ningún dependiente registrado.

La información del Registro siguiente es un ejemplo de la clave de proveedor MSI de host de .NET. Hay cuatro dependientes registrados, incluidos Visual Studio.

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Dependencies\Dotnet_CLI_SharedHost_10.0_x64
    (Default)   REG_SZ    {8A8CC49F-7D1E-45DC-B7B5-35FF61A2C25E}
    Version     REG_SZ    80.40.55332
    DisplayName REG_SZ    Microsoft .NET Host - 10.0.10 (x64)

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Dependencies\Dotnet_CLI_SharedHost_10.0_x64\Dependents\VS.{AEF703B8-D2CC-4343-915C-F54A30B90937}

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Dependencies\Dotnet_CLI_SharedHost_10.0_x64\Dependents\{609A456D-467D-4077-9BA2-B6404F1B1163}

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Dependencies\Dotnet_CLI_SharedHost_10.0_x64\Dependents\{866BECDA-F284-473A-9E84-0CCE816BF06F}

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Dependencies\Dotnet_CLI_SharedHost_10.0_x64\Dependents\{FD5EA214-C690-466F-B8FB-1741881913F9}

Note

Los MSIs individuales se vuelven huérfanos cuando los dependientes permanecen registrados después de quitar un lote, por ejemplo, cuando se interrumpe la desinstalación.

Note

Visual Studio usa un valor conocido, VS.{AEF703B8-D2CC-4343-915C-F54A30B90937}, para registrarse como dependiente. El recuento de referencias real se determina comprobando el manifiesto de instalación de cada instancia de Visual Studio.

Instalaciones implementadas en bin

Las instalaciones implementadas en bin hacen referencia a copias de .NET que no están asociadas a un MSI. Esto se puede lograr ejecutando los scripts de instalación como administrador y estableciendo el directorio de instalación en "Archivos de programa\dotnet". Las instalaciones implementadas en bin pueden complicar la corrección. Los escáneres notificarán vulnerabilidades, pero los administradores no encontrarán MSIs que se desinstalen. DNIM es capaz de detectar instalaciones implementadas de bin.

Detección

EL DNIM se basa en una serie de heurística para identificar agrupaciones y MSIs asociadas a .NET. La detección precisa de instalaciones es fundamental para corregir correctamente un dispositivo que no sea de queja.

Paquetes

Los conjuntos se identifican con sus nombres para mostrar y la información de archivo almacenadas en el registro. Se realizan comprobaciones adicionales en archivos ejecutables para asegurarse de que son instaladores válidos. Esta informatio también se compara con los datos JSON .NET publica para cada versión.

Detección de MSI

DNIM realiza una búsqueda exhaustiva de los datos del componente del instalador almacenados en el registro HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components en para identificar .NET MSIs.

Cada subclave representa un identificador de componente diferente. Los valores de cada clave representan códigos de producto. Tanto el identificador de componente como los códigos de producto se almacenan como GUID empaquetados. El ejemplo siguiente es del componente asociado a dotnet.exe.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\BBB993545ADD68342A9E16F83B5CA481
    40A3E8A8CB38EDC4299598B366C6A11B    REG_SZ    C:\Program Files\dotnet\dotnet.exe
    A75437C333A10ED46B2CF6AB78E7F1FC    REG_SZ    C:\Program Files (x86)\dotnet\dotnet.exe
    79D2396D1F638B04C9CDAC38562B0100    REG_SZ    C:\Program Files\dotnet\dotnet.exe
    EA6D9CBF69367CF4CB81005882631FD6    REG_SZ    C:\Program Files (x86)\dotnet\dotnet.exe
    872D9C61B8AA60F47A4CDF137C8523A3    REG_SZ    C:\Program Files (x86)\dotnet\dotnet.exe
    6235DF10DB18AED4F910D396BBDD7AE5    REG_SZ    C:\Program Files\dotnet\dotnet.exe
    0370151E43A53FE48B564853D1B81FAB    REG_SZ    C:\Program Files\dotnet\dotnet.exe
    F6D22817F79056B46B45655C7495EE9A    REG_SZ    C:\Program Files (x86)\dotnet\dotnet.exe
    D512842CB6C6A404BAE605D564042E50    REG_SZ    C:\Program Files\dotnet\dotnet.exe

Instalaciones implementadas de Bin

Dado que DNIM realiza una búsqueda exhaustiva de los componentes del instalador, los archivos Program Files\dotnet que no están asociados a un MSI se clasifican como instalaciones implementadas por bin.

Classification

La clasificación incorrecta de las instalaciones puede provocar la eliminación o conservación de la instalación incorrecta, lo que podría interrumpir aplicaciones o dejar dispositivos en un estado no compatible.

Una vez identificado un producto (por ejemplo, NET 10), se puede determinar información adicional como su versión (por ejemplo, 10.0.4) y la fase de soporte técnico (por ejemplo, activa). Esto permite a los administradores crear implementaciones flexibles.

Las instalaciones se clasifican aún más según su componente de .NET (ASP.NET Core, SDK, etc.), la arquitectura y el tipo de instalación (agrupación, MSI o bin implementado).

Hay algunos casos especiales que merece la pena mencionar.

.NET Standard 2.1

Garantizar un comportamiento coherente requiere instalaciones para definir su producto, versión y fase de soporte técnico. El paquete de destino para .NET Standard 2.1 presenta un desafío interesante. No contiene código ejecutable y solo proporciona ensamblados de referencia para las API definidas por el estándar. El paquete de destino se envió primero como parte del SDK de .NET Core 3.0.100, pero se incluyó en todos los SDK posteriores hasta .NET 10. Aunque EL DNIM clasificará la versión y el producto en .NET Core 3.0, la fase de soporte técnico siempre se notifica como activa, ya que puede incluirse en los SDK que están en soporte activo.

Note

El paquete de destino .NET Standard 2.1 se quitó de la instalación del SDK en .NET 10. Los SDK descargan automáticamente paquetes de destino que faltan mediante paquetes NuGet al compilar aplicaciones.

bandas de características del SDK de .NET

En .NET Core 1.0 y 1.1, los SDK usaron un esquema de control de versiones similar al runime. El último SDK de .NET Core 1.1 se versionó como 1.1.14 e incluyó el entorno de ejecución 1.1.13.

Las bandas de características del SDK se introdujeron en el SDK 2.1.100 para diferenciar entre las características admitidas en Visual Studio. El SDK se incluye como parte de la versión de .NET Core 2.0.5. El último SDK de 2.0 se versionó como 2.1.202 e incluyó en la versión 2.0.9. El primer SDK que se va a enviar en .NET Core 2.1 se ha versionado como 2.1.300. En versiones posteriores, las bandas de características del SDK siempre comienzan en 100, por ejemplo, 2.2.100, 3.0.100, etc.