Instalações geridas de .NET no Windows

Instalações .NET parcialmente removidas são uma razão comum pela qual software de análise de vulnerabilidades, como o Gestão de vulnerabilidades do Microsoft Defender, reporta um dispositivo. Compreender como funcionam as instalações .NET pode ajudar os administradores a investigar relatórios e a tomar medidas corretivas.

No Windows, componentes .NET como o runtime e o SDK consistem em múltiplos MSIs. Os MSIs individuais não são distribuídos diretamente. Em vez disso, são encadeados para criar feixes.

Aquisição do .NET no Windows

• Pacotes independentes (EXEs) podem ser descarregados do site .NET.
• O WinGet fornece pacotes que contêm os bundles .NET.
• As atualizações de manutenção distribuem os pacotes através do Microsoft Update usando atualizações automáticas, WSUS e o Windows Update Catalogue.
• Fornecedores independentes de software (ISVs) podem redistribuir pacotes .NET como parte do seu software.
• Os fabricantes por vezes incluem cópias pré-instaladas de pacotes .NET nas imagens de fábrica dos novos dispositivos.
• Algumas imagens do Azure Marketplace do Windows incluem cópias pré-instaladas dos bundles.
• Gestores de pacotes terceiros como a Chocolatey também distribuem os pacotes .NET.
• As empresas por vezes reembalam os pacotes usando pacotes proprietários para distribuição interna.
• Alguns hosts de aplicações .NET podem também direcionar os utilizadores para descarregar e instalar pacotes de runtime em falta.

O Visual Studio também pode ser usado para adquirir .NET e utiliza os mesmos MSIs que os pacotes independentes.

Note

O pacote .NET SDK foi fornecido com o Visual Studio até à versão 16.2. A partir do .NET Core 3.0 no Visual Studio 16.3, os pacotes SDK foram substituídos pelos MSIs .NET individuais.

Upgrades

.NET suporta atualizações entre versões de patch dentro de uma versão maior/menor. O .NET 8.0.7 irá atualizar versões anteriores como a 8.0.4 ou 8.0.0, incluindo as versões de pré-lançamento, mas não irá atualizar uma versão maior anterior como o .NET 7.0. O SDK .NET suporta atualizações entre patches dentro de uma faixa de funcionalidades. O SDK 8.0.100 pode ser atualizado para 8.0.103, mas o SDK 8.0.3xx não irá atualizar as bandas de funcionalidades 1xx ou 2xx.

A maioria das melhorias é gerida ao nível do pacote. A versão anterior só é removida quando a nova é instalada. Existem duas exceções: os MSIs do host .NET e do Módulo ASP.NET Core são atualizados no local.

A partir do .NET 8, os utilizadores têm a opção de adiar a remoção da versão anterior de um bundle.

Composição de feixes e contagem de referências

Os bundles são compostos por múltiplos MSIs, alguns dos quais são partilhados entre vários bundles.

• O pacote de runtime contém três MSIs que também são incluídos nos pacotes de tempo de execução e SDK do ambiente de trabalho.
• O pacote desktop inclui um MSI adicional que é partilhado com o pacote SDK.
• O SDK inclui MSIs adicionais que contêm a CLI, templates e packs de direcionamento usados para criar e construir aplicações .NET.

Os MSIs partilhados são geridos através da contagem de referências. Cada MSI .NET cria uma chave de registo chamada chave de fornecedor, que permite a um bundle registar-se como dependente. Se um MSI já estiver instalado, o pacote só atualiza a informação de registo. Os pacotes são não registados quando são removidos. Os MSIs partilhados só são removidos quando não há dependentes registados.

A informação do registo abaixo é um exemplo da chave de provedor MSI do host .NET. Existem quatro dependentes registados, incluindo o 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

MSIs individuais tornam-se órfãos quando os dependentes permanecem registados após a remoção de um bundle, por exemplo, quando a desinstalação é interrompida.

Note

O Visual Studio utiliza um valor bem conhecido, VS.{AEF703B8-D2CC-4343-915C-F54A30B90937}, para se registar como dependente. A contagem real de referências é determinada verificando o manifesto de instalação para cada instância do Visual Studio.

Instalações implantadas em bin

Instalações bin deployadas referem-se a cópias de .NET que não estão associadas a um MSI. Isto pode ser conseguido executando os scripts de instalação como administrador e definindo o diretório de instalação para 'Program Files\dotnet'. Instalações implantadas em bin podem complicar a remediação. Os scanners reportam vulnerabilidades, mas os administradores não encontram MSIs para desinstalar. O DNIM consegue detetar instalações bin-deployed.

Deteção

O DNIM baseia-se em várias heurísticas para identificar fibrados e MSIs associados ao .NET. Detetar instalações com precisão é fundamental para remediar com sucesso dispositivos que não sejam reclamações.

Pacotes

Os bundles são identificados pelos seus nomes de exibição e informações de ficheiros armazenadas no registo. São realizadas verificações adicionais aos executáveis para garantir que são instaladores válidos. Esta informação também é comparada com os dados JSON que o .NET publica em cada lançamento.

Deteção MSI

O DNIM realiza uma pesquisa exaustiva entre os dados do componente do instalador armazenados no registo abaixo HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components para identificar MSIs .NET.

Cada subchave representa um ID de componente diferente. Os valores sob cada chave representam códigos de produto. Tanto o ID do componente como os códigos de produto são armazenados como GUIDs embalados. O exemplo abaixo é do componente associado 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

Instalações implantadas em bin

Como o DNIM realiza uma pesquisa exaustiva dos componentes do instalador, quaisquer ficheiros não Program Files\dotnet associados a um MSI são classificados como instalações bin deployed.

Classification

A classificação incorreta das instalações pode resultar na remoção ou manutenção da instalação errada, podendo quebrar aplicações ou deixar os dispositivos num estado não conforme.

Uma vez identificado um produto (por exemplo, NET 10), podem ser determinadas informações adicionais como o seu lançamento (por exemplo, 10.0.4) e a fase de suporte (por exemplo, ativo). Isto permite aos administradores criar implementações flexíveis.

As instalações são ainda classificadas de acordo com o seu componente .NET (ASP.NET Core, SDK, etc.), arquitetura e tipo de instalação (bundle, MSI ou bin deployed).

Há alguns casos especiais que merecem ser mencionados.

.NET Padrão 2.1

Garantir um comportamento consistente exige que as instalações definam o seu produto, lançamento e fase de suporte. O pacote de mira para .NET Standard 2.1 apresenta um desafio interessante. Não contém código executável e apenas fornece assemblies de referência para as APIs definidas pelo standard. O pacote de direcionamento foi inicialmente enviado como parte do SDK .NET Core 3.0.100, mas foi incluído em todos os SDKs subsequentes até ao .NET 10. Embora o DNIM classifique o lançamento e o produto sob o .NET Core 3.0, a fase de suporte é sempre reportada como ativa, pois pode estar incluída em SDKs em suporte ativo.

Note

O pacote de direcionamento .NET Standard 2.1 foi removido da instalação do SDK no .NET 10. Os SDKs descarregam automaticamente pacotes de direcionamento em falta usando pacotes NuGet ao construir aplicações.

Bandas de destaque do SDK .NET

No .NET Core 1.0 e 1.1, os SDKs usavam um esquema de versionamento semelhante ao runime. O último SDK em .NET Core 1.1 foi versionado como 1.1.14 e incluía o runtime 1.1.13.

As bandas de funcionalidades do SDK foram introduzidas no SDK 2.1.100 para diferenciar as funcionalidades suportadas no Visual Studio. O SDK foi lançado como parte da versão .NET Core 2.0.5. O último SDK 2.0 foi versionado como 2.1.202 e incluído na versão 2.0.9. O primeiro SDK a ser lançado em .NET Core 2.1 foi versionado como 2.1.300. Em lançamentos posteriores, as bandas de destaque dos SDK começam sempre no número 100, por exemplo, 2.2.100, 3.0.100, etc.