Instalações de .NET gerenciadas no Windows

Instalações de .NET parcialmente removidas são um motivo comum pelo qual o software de verificação de vulnerabilidade, como Gerenciamento de Vulnerabilidades do Microsoft Defender, relatará um dispositivo. Entender como as instalações .NET funcionam pode ajudar os administradores a investigar relatórios e executar ações corretivas.

Em Windows, .NET componentes como o runtime e o SDK consistem em várias MSIs. MSIs individuais não são distribuídas diretamente. Em vez disso, eles são encadeados para criar pacotes.

Adquirir .NET em Windows

• Os EXEs (pacotes autônomos) podem ser baixados no site do .NET.
• O WinGet fornece pacotes que contêm os pacotes de .NET.
• As atualizações de manutenção distribuem os pacotes por meio do Microsoft Update usando atualizações automáticas, WSUS e o Catálogo de Windows Update.
• Os ISVs (fornecedores independentes de software) podem redistribuir pacotes de .NET como parte de seu software.
• Às vezes, os OEMs incluem cópias pré-instaladas de pacotes de .NET nas imagens de fábrica de novos dispositivos.
• Algumas Azure imagens do marketplace de Windows incluem cópias pré-instaladas dos pacotes.
• Gerentes de pacotes de terceiros, como a Chocolatey, também distribuem os pacotes de .NET.
• Às vezes, as empresas reempacotam os pacotes usando pacotes proprietários para distribuição interna.
• Alguns .NET hosts de aplicativo também podem direcionar os usuários para baixar e instalar pacotes de runtime ausentes.

Visual Studio também pode ser usado para adquirir .NET e usa as mesmas MSIs que os pacotes autônomos.

Note

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

Upgrades

.NET dá suporte a atualizações entre versões de patch em uma versão principal/secundária. .NET 8.0.7 atualizará versões anteriores, como 8.0.4 ou 8.0.0, incluindo versões de pré-lançamento, mas não atualizará uma versão principal anterior, como .NET 7.0. O SDK do .NET dá suporte a atualizações entre patches dentro de uma faixa de recursos. O SDK 8.0.100 pode ser atualizado para 8.0.103, mas o SDK 8.0.3xxx não atualizará as faixas de recursos 1xx ou 2xxx.

A maioria das atualizações é tratada no nível do pacote. A versão anterior só é removida depois que a nova versão é instalada. Há duas exceções: o host .NET e as MSIs do módulo ASP.NET Core são atualizados em vigor.

A partir do .NET 8, os usuários têm a opção de adiar a remoção da versão anterior de um pacote.

Composição de pacote e contagem de referência

Os pacotes são compostos de várias MSIs, algumas das quais são compartilhadas entre vários pacotes.

• O pacote de runtime contém três MSIs que também são fornecidos nos pacotes de runtime e SDK da área de trabalho.
• O pacote da área de trabalho inclui uma MSI adicional que é compartilhada com o pacote do SDK.
• O SDK inclui MSIs adicionais que contêm a CLI, modelos e pacotes de destino usados para criar e criar aplicativos .NET.

AS MSIs compartilhadas são gerenciadas usando a contagem de referência. Cada .NET MSI cria uma chave do Registro chamada chave de provedor que permite que um pacote se registre como dependente. Se uma MSI já estiver instalada, o pacote atualizará apenas as informações de registro. Os pacotes não são registrados quando são removidos. As MSIs compartilhadas só são removidas quando não há dependentes registrados.

As informações do Registro abaixo são um exemplo da chave do provedor MSI do host .NET. Há quatro dependentes registrados, incluindo 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

As MSIs individuais ficam órfãs quando os dependentes permanecem registrados depois que um pacote é removido, por exemplo, quando a desinstalação é interrompida.

Note

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

Instalações implantadas por bin

As instalações implantadas por bin referem-se a cópias de .NET que não estão associadas a uma MSI. Isso pode ser feito executando os scripts de instalação como administrador e definindo o diretório de instalação como 'Arquivos de Programas\dotnet'. As instalações implantadas por bin podem complicar a correção. Os scanners relatarão vulnerabilidades, mas os administradores não encontrarão MSIs para desinstalar. O DNIM é capaz de detectar instalações implantadas na lixeira.

Detecção

O DNIM depende de uma série de heurísticas para identificar pacotes e MSIs associados a .NET. Detectar instalações com precisão é essencial para corrigir com êxito dispositivos que não são de reclamação.

Pacotes

Os pacotes são identificados usando seus nomes de exibição e informações de arquivo armazenadas no registro. Verificações adicionais são executadas em executáveis para garantir que sejam instaladores válidos. Essa informatio também é comparada com os dados JSON .NET publica para cada versão.

Detecção de MSI

O DNIM executa uma pesquisa exaustiva em relação aos dados de componente do instalador armazenados no registro HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components em que se identifica .NET MSIs.

Cada subchave representa uma ID de componente diferente. Os valores em cada chave representam códigos do produto. A ID do componente e os códigos do produto são armazenados como GUIDs empacotados. O exemplo a seguir é do componente associado dotnet.exea .

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 por bin

Como o DNIM executa uma pesquisa exaustiva de componentes do instalador, todos os arquivos em Program Files\dotnet não associados a uma MSI são classificados como instalações implantadas na lixeira.

Classification

A classificação incorreta de instalações pode resultar na remoção ou retenção da instalação incorreta, potencialmente interrompendo aplicativos ou deixando dispositivos em um estado não compatível.

Depois que um produto (por exemplo, NET 10) é identificado, informações adicionais como sua versão (por exemplo, 10.0.4) e fase de suporte (por exemplo, ativa) podem ser determinadas. Isso permite que os administradores criem implantações flexíveis.

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

Há alguns casos especiais que vale a pena mencionar.

.NET Standard 2.1

Garantir um comportamento consistente requer instalações para definir o produto, a versão e a fase de suporte. O pacote de destino para .NET Standard 2.1 apresenta um desafio interessante. Ele não contém código executável e fornece apenas assemblies de referência para as APIs definidas pelo padrão. O pacote de destino foi enviado pela primeira vez como parte do SDK do .NET Core 3.0.100, mas foi incluído em todos os SDKs subsequentes até .NET 10. Embora o DNIM classifique a versão e o produto em .NET Core 3.0, a fase de suporte é sempre relatada como ativa, pois pode ser incluída em SDKs que estão em suporte ativo.

Note

O pacote de destino do .NET Standard 2.1 foi removido da instalação do SDK no .NET 10. Os SDKs baixam automaticamente pacotes de destino ausentes usando pacotes NuGet ao criar aplicativos.

.NET faixas de recursos do SDK

No .NET Core 1.0 e 1.1, os SDKs usavam um esquema de controle de versão semelhante ao runime. O último SDK no .NET Core 1.1 foi versão 1.1.14 e incluiu o runtime 1.1.13.

As bandas de recursos do SDK foram introduzidas no SDK 2.1.100 para diferenciar os recursos com suporte no Visual Studio. O SDK enviado como parte da versão do .NET Core 2.0.5. O último SDK 2.0 foi versão 2.1.202 e incluído na versão 2.0.9. O primeiro SDK a ser enviado no .NET Core 2.1 foi lançado como 2.1.300. Em versões posteriores, as bandas de recursos do SDK sempre começam em 100, por exemplo, 2.2.100, 3.0.100, etc.