Installazioni di .NET gestite in Windows

Le installazioni di .NET parzialmente rimosse sono un motivo comune per cui il software di analisi delle vulnerabilità come Gestione delle vulnerabilità di Microsoft Defender segnala un dispositivo. Informazioni sul funzionamento delle installazioni di .NET consente agli amministratori di analizzare i report ed eseguire azioni correttive.

In Windows, .NET componenti come il runtime e l'SDK sono costituiti da più istanza gestita. Le singole istanze del servizio gestito non vengono distribuite direttamente. Vengono invece concatenati per creare bundle.

Acquisizione di .NET su Windows

• I bundle autonomi (EXEs) possono essere scaricati dal sito Web di .NET.
• WinGet fornisce pacchetti che contengono i bundle .NET.
• Gli aggiornamenti di manutenzione distribuiscono i bundle tramite Microsoft Update usando aggiornamenti automatici, WSUS e il catalogo Windows Update.
• I fornitori di software indipendenti (ISV) possono ridistribuire i bundle .NET come parte del software.
• Gli OEM includono talvolta copie preinstallate di bundle .NET nelle immagini factory dei nuovi dispositivi.
• Alcune immagini del marketplace Azure di Windows includono copie preinstallate dei bundle.
• Anche i gestori di pacchetti di terze parti come Chocolatey distribuiscono i bundle .NET.
• Le aziende talvolta ricreano il pacchetto usando pacchetti proprietari per la distribuzione interna.
• Alcuni host di applicazioni .NET potrebbero anche indirizzare gli utenti a scaricare e installare bundle di runtime mancanti.

Visual Studio può essere usato anche per acquisire .NET e usa le stesse istanze del servizio gestito dei bundle autonomi.

Note

Il bundle .NET SDK fornito con Visual Studio fino alla versione 16.2. A partire da .NET Core 3.0 in Visual Studio 16.3, i bundle SDK sono stati sostituiti con i singoli .NET MSI.

Upgrades

.NET supporta gli aggiornamenti tra le versioni delle patch all'interno di una versione principale/secondaria. .NET 8.0.7 aggiornerà le versioni precedenti come 8.0.4 o 8.0.0, incluse le versioni non definitive, ma non aggiornerà una versione principale precedente come .NET 7.0. L'SDK di .NET supporta gli aggiornamenti tra patch all'interno di una banda di funzionalità. L'SDK 8.0.100 può essere aggiornato alla versione 8.0.103, ma l'SDK 8.0.3xx non aggiornerà le bande di funzionalità 1xx o 2xx.

La maggior parte degli aggiornamenti viene gestita a livello di bundle. La versione precedente viene rimossa solo dopo l'installazione della nuova versione. Esistono due eccezioni: l'host .NET e le istanze msi del modulo ASP.NET Core vengono aggiornate sul posto.

A partire da .NET 8, gli utenti hanno la possibilità di posticipare la rimozione della versione precedente di un bundle.

Composizione del bundle e conteggio dei riferimenti

I bundle sono costituiti da più istanza gestita, alcune delle quali sono condivise tra più bundle.

• Il bundle di runtime contiene tre istanze msi che vengono fornite anche nel runtime desktop e nei bundle SDK.
• Il bundle desktop include un'identità del servizio gestita aggiuntiva condivisa con il bundle SDK.
• L'SDK include msi aggiuntivi che contengono l'interfaccia della riga di comando, i modelli e i pacchetti di destinazione usati per creare e compilare applicazioni .NET.

Le istanze msi condivise vengono gestite usando il conteggio dei riferimenti. Ogni .NET MSI crea una chiave del Registro di sistema denominata chiave del provider che consente a un bundle di registrarsi come dipendente. Se un'identità del servizio gestito è già installata, il bundle aggiorna solo le informazioni di registrazione. I bundle vengono annullati quando vengono rimossi. Le istanze del servizio gestito condivise vengono rimosse solo una volta che non sono presenti dipendenti registrati.

Le informazioni del Registro di sistema seguenti sono un esempio della chiave del provider MSI host .NET. Sono presenti quattro dipendenti registrati, tra cui 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

I singoli msi diventano orfani quando i dipendenti rimangono registrati dopo la rimozione di un bundle, ad esempio quando la disinstallazione viene interrotta.

Note

Visual Studio usa un valore noto, VS.{AEF703B8-D2CC-4343-915C-F54A30B90937}, per registrarsi come dipendente. Il conteggio effettivo dei riferimenti viene determinato controllando il manifesto dell'installazione per ogni istanza di Visual Studio.

Installazioni distribuite bin

Le installazioni distribuite bin fanno riferimento a copie di .NET non associate a un'identità del servizio gestito. A tale scopo, eseguire gli script di installazione come amministratore e impostare la directory di installazione su 'Programmi\dotnet'. Le installazioni distribuite bin possono complicare la correzione. Gli scanner segnalano le vulnerabilità, ma gli amministratori non troveranno le istanze del servizio gestito da disinstallare. DNIM è in grado di rilevare le installazioni distribuite nel bin.

Scoperta

DNIM si basa su una serie di euristiche per identificare i bundle e le istanze msi associati a .NET. Il rilevamento accurato delle installazioni è fondamentale per correggere correttamente un dispositivo non reclamo.

Pacchetti

I bundle vengono identificati usando i nomi visualizzati e le informazioni sui file archiviati nel Registro di sistema. Vengono eseguiti controlli aggiuntivi sui file eseguibili per assicurarsi che siano programmi di installazione validi. Questa informazione viene confrontata anche con i dati JSON .NET pubblica per ogni versione.

Rilevamento MSI

DNIM esegue una ricerca completa sui dati del componente del programma di installazione archiviati nel registro HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components in per identificare .NET MSI.

Ogni sottochiave rappresenta un ID componente diverso. I valori in ogni chiave rappresentano i codici prodotto. Sia l'ID componente che i codici prodotto vengono archiviati come GUID compressi. L'esempio seguente è del componente associato 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

Installazioni distribuite bin

Poiché DNIM esegue una ricerca completa dei componenti del programma di installazione, tutti i file Program Files\dotnet non associati a un'identità del servizio gestito vengono classificati come installazioni bin distribuite.

Classification

La classificazione non corretta delle installazioni può comportare la rimozione o la conservazione dell'installazione errata, l'interruzione di applicazioni o l'uscita dei dispositivi in uno stato non conforme.

Una volta identificato un prodotto (ad esempio, NET 10), è possibile determinare informazioni aggiuntive come la versione (ad esempio 10.0.4) e la fase di supporto (ad esempio, attiva). In questo modo gli amministratori possono creare distribuzioni flessibili.

Le installazioni vengono ulteriormente classificate in base al componente .NET (ASP.NET Core, SDK e così via), all'architettura e al tipo di installazione (bundle, MSI o bin distribuito).

Ci sono alcuni casi speciali che vale la pena menzionare.

.NET Standard 2.1

Garantire un comportamento coerente richiede installazioni per definire il prodotto, il rilascio e la fase di supporto. Il targeting pack per .NET Standard 2.1 presenta una sfida interessante. Non contiene codice eseguibile e fornisce solo assembly di riferimento per le API definite dallo standard. Il pacchetto di destinazione è stato fornito per la prima volta come parte del .NET Core 3.0.100 SDK, ma è stato incluso in ogni SDK successivo fino a .NET 10. Mentre DNIM classifica il rilascio e il prodotto in .NET Core 3.0, la fase di supporto viene sempre segnalata come attiva perché può essere inclusa negli SDK che sono in supporto attivo.

Note

Il pacchetto di destinazione .NET Standard 2.1 è stato rimosso dall'installazione dell'SDK in .NET 10. Gli SDK scaricano automaticamente pacchetti di destinazione mancanti usando pacchetti NuGet durante la compilazione di applicazioni.

bande di funzionalità .NET SDK

In .NET Core 1.0 e 1.1, gli SDK usavano uno schema di controllo delle versioni simile al runime. L'ultimo SDK in .NET Core 1.1 è stato aggiornato come 1.1.14 e includeva il runtime 1.1.13.

Le funzionalità SDK sono state introdotte nell'SDK 2.1.100 per distinguere tra le funzionalità supportate in Visual Studio. L'SDK è stato fornito come parte della versione .NET Core 2.0.5. L'ultima versione dell'SDK 2.0 è stata rilasciata come 2.1.202 e inclusa nella versione 2.0.9. Il primo SDK da distribuire in .NET Core 2.1 è stato aggiornato come 2.1.300. Nelle versioni successive, le bande di funzionalità SDK iniziano sempre a 100, ad esempio 2.2.100, 3.0.100 e così via.