Installations de .NET managées sur Windows

Les installations partiellement supprimées .NET sont une raison courante pour laquelle les logiciels d’analyse des vulnérabilités comme Microsoft Defender Vulnerability Management signalent un appareil. Comprendre comment .NET les installations peuvent aider les administrateurs à examiner les rapports et à prendre des mesures correctives.

Sur Windows, .NET composants tels que le runtime et le SDK se composent de plusieurs MSIs. Les MSI individuelles ne sont pas distribuées directement. Au lieu de cela, ils sont chaînés pour créer des bundles.

Acquisition de .NET sur Windows

• Les offres groupées autonomes (EXE) peuvent être téléchargées à partir du site web .NET.
• WinGet fournit des packages qui contiennent les offres groupées .NET.
• Les mises à jour de maintenance distribuent les offres groupées via Microsoft Update à l’aide des mises à jour automatiques, WSUS et du catalogue Windows Update.
• Les éditeurs de logiciels indépendants (ISV) peuvent redistribuer des offres groupées .NET dans le cadre de leur logiciel.
• Les OEM incluent parfois des copies préinstallées d’offres groupées de .NET dans les images de fabrique de nouveaux appareils.
• Certaines images de Azure place de marché de Windows incluent des copies préinstallées des bundles.
• Des gestionnaires de packages tiers comme Chocolatey distribuent également les offres groupées .NET.
• Les entreprises repackagent parfois les bundles à l’aide de packages propriétaires pour la distribution interne.
• Certains hôtes d’applications .NET peuvent également diriger les utilisateurs vers le téléchargement et l’installation de bundles d’exécution manquants.

Visual Studio pouvez également être utilisé pour acquérir .NET et utiliser les mêmes MSIs que les offres groupées autonomes.

Note

Le kit sdk .NET fourni avec Visual Studio jusqu’à la version 16.2. À compter de .NET Core 3.0 dans Visual Studio 16.3, les offres groupées du KIT de développement logiciel (SDK) ont été remplacées par les MSIs individuelles .NET.

Upgrades

.NET prend en charge les mises à niveau entre les versions de correctifs dans une version majeure/mineure. .NET 8.0.7 met à niveau les versions précédentes comme 8.0.4 ou 8.0.0, y compris les versions préliminaires, mais ne met pas à niveau une version majeure précédente comme .NET 7.0. Le sdk .NET prend en charge les mises à niveau entre les correctifs au sein d’une bande de fonctionnalités. Le SDK 8.0.100 peut être mis à niveau vers 8.0.103, mais le SDK 8.0.3xx ne met pas à niveau les bandes de fonctionnalités 1xx ou 2xx.

La majorité des mises à niveau sont gérées au niveau de l’offre groupée. La version précédente n’est supprimée qu’une fois la nouvelle version installée. Il existe deux exceptions : l’hôte .NET et les msis de module ASP.NET Core sont mis à jour en place.

À compter de .NET 8, les utilisateurs ont la possibilité de différer la suppression de la version précédente d’un bundle.

Composition de bundle et comptage de références

Les bundles sont composés de plusieurs MSIs, dont certains sont partagés entre plusieurs bundles.

• Le bundle d’exécution contient trois MSIs qui sont également fournies dans les offres groupées du runtime de bureau et du KIT de développement logiciel (SDK).
• L’offre groupée de bureau inclut une msi supplémentaire partagée avec l’offre groupée du Kit de développement logiciel (SDK).
• Le SDK inclut des MSIs supplémentaires qui contiennent l’interface CLI, les modèles et les packs de ciblage utilisés pour créer et générer des applications .NET.

Les MSIS partagées sont gérées à l’aide du comptage de références. Chaque .NET MSI crée une clé de Registre appelée clé de fournisseur qui permet à un bundle de s’inscrire en tant que dépendante. Si une msi est déjà installée, le bundle met uniquement à jour les informations d’inscription. Les offres groupées ne sont pas inscrites lorsqu’elles sont supprimées. Les MSIs partagées ne sont supprimées qu’une fois qu’il n’y a pas de dépendances inscrites.

Les informations de Registre ci-dessous sont un exemple de clé de fournisseur MSI hôte .NET. Il existe quatre personnes dépendantes inscrites, y compris 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

Les MSI individuelles deviennent orphelines lorsque les dépendants restent inscrits après la suppression d’un bundle, par exemple lorsque la désinstallation est interrompue.

Note

Visual Studio utilise une valeur connue, VS.{AEF703B8-D2CC-4343-915C-F54A30B90937}pour s’inscrire en tant que dépendant. Le nombre de références réel est déterminé en vérifiant le manifeste d’installation pour chaque instance de Visual Studio.

Installations déployées par bin

Les installations déployées par compartiment font référence à des copies de .NET qui ne sont pas associées à une msi. Pour ce faire, exécutez les scripts d’installation en tant qu’administrateur et définissez le répertoire d’installation sur « Program Files\dotnet ». Les installations déployées par bin peuvent compliquer la correction. Les scanneurs signalent des vulnérabilités, mais les administrateurs ne trouveront pas de MSIs à désinstaller. DNIM est en mesure de détecter les installations déployées par le compartiment.

Détection

DNIM s’appuie sur un certain nombre d’heuristiques pour identifier les offres groupées et les MSIs associés à .NET. La détection précise des installations est essentielle pour corriger correctement un appareil sans plainte.

Offres groupées

Les bundles sont identifiés à l’aide de leurs noms d’affichage et informations de fichier stockés dans le Registre. Des vérifications supplémentaires sont effectuées sur les exécutables pour s’assurer qu’ils sont des programmes d’installation valides. Cette informatio est également comparée aux données JSON .NET publie pour chaque version.

Détection MSI

DNIM effectue une recherche exhaustive sur les données des composants du programme d’installation stockées dans l’inscription sous HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components pour identifier .NET MSIs.

Chaque sous-clé représente un ID de composant différent. Les valeurs sous chaque clé représentent les codes de produit. L’ID de composant et les codes de produit sont stockés sous forme de GUID packés. L’exemple ci-dessous concerne le composant associé à 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

Installations déployées par bin

Étant donné que DNIM effectue une recherche exhaustive des composants du programme d’installation, tous les fichiers qui Program Files\dotnet ne sont pas associés à une msi sont classés comme installations déployées par bin.

Classification

Une classification incorrecte des installations peut entraîner la suppression ou la conservation de l’installation incorrecte, des applications potentiellement cassantes ou laissant des appareils dans un état non conforme.

Une fois qu’un produit (par exemple, NET 10) est identifié, des informations supplémentaires telles que sa version (par exemple, 10.0.4) et la phase de prise en charge (par exemple, active) peuvent être déterminées. Cela permet aux administrateurs de créer des déploiements flexibles.

Les installations sont classées en fonction de leur composant .NET (ASP.NET Core, SDK, etc.), de l’architecture et du type d’installation (bundle, MSI ou bin déployé).

Il y a quelques cas particuliers qui méritent d’être mentionnés.

.NET Standard 2.1

S’assurer que le comportement cohérent nécessite des installations pour définir leur produit, leur mise en production et leur phase de prise en charge. Le pack de ciblage pour .NET Standard 2.1 présente un défi intéressant. Il ne contient pas de code exécutable et fournit uniquement des assemblys de référence pour les API définies par la norme. Le pack de ciblage a d’abord été fourni dans le cadre du KIT SDK .NET Core 3.0.100, mais il a été inclus dans tous les kits SDK suivants jusqu’à .NET 10. Bien que DNIM classifie la version et le produit sous .NET Core 3.0, la phase de prise en charge est toujours signalée comme active, car elle peut être incluse dans les kits SDK qui sont pris en charge actif.

Note

Le pack de ciblage .NET Standard 2.1 a été supprimé de l’installation du Kit de développement logiciel (SDK) dans .NET 10. Les kits SDK téléchargent automatiquement les packs de ciblage manquants à l’aide de packages NuGet lors de la génération d’applications.

.NET bandes de fonctionnalités du Kit de développement logiciel (SDK)

Dans .NET Core 1.0 et 1.1, les kits SDK utilisent un schéma de gestion de version similaire au runime. Le dernier SDK de .NET Core 1.1 a été versionné en tant que version 1.1.14 et inclut le runtime 1.1.13.

Les bandes de fonctionnalités du Kit de développement logiciel (SDK) ont été introduites dans le SDK 2.1.100 pour différencier les fonctionnalités prises en charge dans Visual Studio. Le SDK est fourni dans le cadre de la version .NET Core 2.0.5. Le dernier SDK 2.0 a été versionné en tant que version 2.1.202 et inclus dans la version 2.0.9. Le premier SDK à expédier dans .NET Core 2.1 a été versionné en tant que version 2.1.300. Dans les versions ultérieures, les bandes de fonctionnalités du SDK commencent toujours à 100, par exemple, 2.2.100, 3.0.100, etc.