Instalacje zarządzane .NET w Windows

Częściowo usunięte instalacje .NET są typowym powodem, dla którego oprogramowanie do skanowania luk w zabezpieczeniach, takie jak Zarządzanie lukami w zabezpieczeniach w usłudze Microsoft Defender, zgłosi urządzenie. Zrozumienie sposobu działania instalacji .NET może pomóc administratorom w badaniu raportów i podejmowaniu działań naprawczych.

W Windows składniki .NET, takie jak środowisko uruchomieniowe i zestaw SDK, składają się z wielu msI. Poszczególne msI nie są bezpośrednio dystrybuowane. Zamiast tego są one połączone w łańcuch, aby tworzyć pakiety.

Uzyskiwanie .NET na Windows

• Pakiety autonomiczne (EXE) można pobrać z witryny internetowej .NET.
• WinGet udostępnia pakiety zawierające pakiety .NET.
• Aktualizacje obsługi dystrybuują pakiety za pośrednictwem usługi Microsoft Update przy użyciu aktualizacji automatycznych, usług WSUS i katalogu Windows Update.
• Niezależni dostawcy oprogramowania mogą rozpowszechniać pakiety .NET w ramach oprogramowania.
• Producenci OEM czasami zawierają wstępnie zainstalowane kopie pakietów .NET w obrazach fabrycznych nowych urządzeń.
• Niektóre Azure obrazy witryny Marketplace Windows obejmują wstępnie zainstalowane kopie pakietów.
• Menedżerowie pakietów innych firm, tacy jak Chocolatey, również rozpowszechniają pakiety .NET.
• Przedsiębiorstwa czasami ponownie pakować pakiety przy użyciu zastrzeżonych pakietów do dystrybucji wewnętrznej.
• Niektóre hosty aplikacji .NET mogą również kierować użytkowników do pobierania i instalowania brakujących pakietów środowiska uruchomieniowego.

Visual Studio można również użyć do uzyskiwania .NET i używa tych samych interfejsów MSI co pakiety autonomiczne.

Note

Pakiet zestawu SDK .NET dostarczany z Visual Studio do wersji 16.2. Począwszy od wersji .NET Core 3.0 w wersji Visual Studio 16.3, zestawy SDK zostały zastąpione poszczególnymi .NET msI.

Upgrades

.NET obsługuje uaktualnienia między wersjami poprawek w wersji głównej/pomocniczej. .NET 8.0.7 uaktualni poprzednie wersje, takie jak 8.0.4 lub 8.0.0, w tym wersje wstępne, ale nie uaktualnią poprzedniej wersji głównej, takiej jak .NET 7.0. Zestaw SDK .NET obsługuje uaktualnienia między poprawkami w pasmie funkcji. Zestaw SDK 8.0.100 można uaktualnić do wersji 8.0.103, ale zestaw SDK 8.0.3xx nie uaktualni pasm funkcji 1xx ani 2xx.

Większość uaktualnień jest obsługiwana na poziomie pakietu. Poprzednia wersja jest usuwana tylko po zainstalowaniu nowej wersji. Istnieją dwa wyjątki: host .NET i msI modułu ASP.NET Core są aktualizowane.

Począwszy od .NET 8, użytkownicy mają możliwość odroczenia usuwania poprzedniej wersji pakietu.

Kompozycja pakietu i zliczanie odwołań

Pakiety składają się z wielu msI, z których niektóre są współdzielone między wieloma pakietami.

• Pakiet środowiska uruchomieniowego zawiera trzy interfejsy MSI dostarczane również w środowisku uruchomieniowym pulpitu i pakietach zestawu SDK.
• Pakiet pulpitu zawiera dodatkową tożsamość usługi zarządzanej udostępnioną pakietowi SDK.
• Zestaw SDK zawiera dodatkowe interfejsy MSI zawierające interfejs wiersza polecenia, szablony i pakiety docelowe używane do tworzenia i tworzenia aplikacji .NET.

Udostępnione interfejsy MSI są zarządzane przy użyciu zliczania odwołań. Każda .NET tożsamości usługi zarządzanej tworzy klucz rejestru nazywany kluczem dostawcy, który umożliwia pakietowi zarejestrowanie się jako zależne. Jeśli tożsamość usługi zarządzanej jest już zainstalowana, pakiet aktualizuje tylko informacje o rejestracji. Pakiety są wyrejestrowane po ich usunięciu. Udostępnione interfejsy MSI są usuwane tylko wtedy, gdy nie ma żadnych zarejestrowanych zależności.

Poniższe informacje rejestru są przykładem klucza dostawcy msi hosta .NET. Istnieją cztery zarejestrowane zależności, w tym 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

Poszczególne msI stają się oddzielone, gdy zależności pozostają zarejestrowane po usunięciu pakietu, na przykład po przerwaniu odinstalowywania.

Note

Visual Studio używa dobrze znanej wartości , VS.{AEF703B8-D2CC-4343-915C-F54A30B90937}aby zarejestrować się jako zależny. Rzeczywista liczba odwołań jest określana przez sprawdzenie manifestu instalacji dla każdego wystąpienia Visual Studio.

Instalacje wdrożone w pojemniku

Instalacje wdrożone w pojemniku odnoszą się do kopii .NET, które nie są skojarzone z tożsamością usługi zarządzanej. Można to osiągnąć, uruchamiając skrypty instalacji jako administrator i ustawiając katalog instalacyjny na "Program Files\dotnet". Instalacje wdrożone w pojemniku mogą komplikować korygowanie. Skanery będą zgłaszać luki w zabezpieczeniach, ale administratorzy nie znajdą identyfikatorów MSI do odinstalowania. DniM jest w stanie wykryć wdrożone instalacje bin.

Wykrywanie

DNIM opiera się na wielu heurystyce do identyfikowania pakietów i MSI skojarzonych z .NET. Dokładne wykrywanie instalacji ma kluczowe znaczenie dla pomyślnego skorygowania urządzeń niebędących skargami.

Bundles

Pakiety są identyfikowane przy użyciu ich nazw wyświetlanych i informacji o plikach przechowywanych w rejestrze. Dodatkowe kontrole są wykonywane na plikach wykonywalnych, aby upewnić się, że są prawidłowymi instalatorami. Ta informacja jest również porównywana z danymi JSON .NET publikowanymi dla każdej wersji.

Wykrywanie tożsamości usługi zarządzanej

DNIM wykonuje wyczerpujące wyszukiwanie danych składników instalatora przechowywanych w rejestrze w HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components celu zidentyfikowania .NET MSI.

Każdy podklucz reprezentuje inny identyfikator składnika. Wartości w każdym kluczu reprezentują kody produktów. Zarówno identyfikator składnika, jak i kody produktów są przechowywane jako pakowane identyfikatory GUID. Poniższy przykład jest składnikiem skojarzonym z dotnet.exeprogramem .

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

Instalacje wdrożone w pojemniku

Ponieważ DNIM wykonuje wyczerpujące wyszukiwanie składników instalatora, wszystkie pliki, które Program Files\dotnet nie są skojarzone z tożsamością msi, są klasyfikowane jako instalacje wdrożone w pojemniku.

Classification

Nieprawidłowa klasyfikacja instalacji może spowodować usunięcie lub zachowanie nieprawidłowej instalacji, potencjalnie powodujące niezgodność aplikacji lub pozostawienie urządzeń w stanie niezgodnym.

Po zidentyfikowaniu produktu (na przykład net 10) można określić dodatkowe informacje, takie jak jego wydanie (na przykład 10.0.4) i faza pomocy technicznej (na przykład aktywna). Dzięki temu administratorzy mogą tworzyć elastyczne wdrożenia.

Instalacje są dalej klasyfikowane zgodnie ze składnikiem .NET (ASP.NET Core, SDK itp.), architekturą i typem instalacji (pakiet, msi lub wdrożony pojemnik).

Warto wspomnieć o niektórych specjalnych przypadkach.

.NET Standard 2.1

Zapewnienie spójnego zachowania wymaga od instalacji definiowania ich produktu, wydania i fazy pomocy technicznej. Pakiet docelowy dla .NET Standard 2.1 stanowi interesujące wyzwanie. Nie zawiera kodu wykonywalnego i udostępnia tylko zestawy referencyjne dla interfejsów API zdefiniowanych przez standard. Pakiet docelowy został najpierw dostarczony jako część zestawu SDK platformy .NET Core 3.0.100, ale został uwzględniony w każdym kolejnym zestawie SDK do czasu .NET 10. Podczas gdy dniM będzie klasyfikować wydanie i produkt w ramach .NET Core 3.0, faza pomocy technicznej jest zawsze zgłaszana jako aktywna, ponieważ może być uwzględniona w zestawach SDK, które są w aktywnej obsłudze.

Note

Pakiet docelowy .NET Standard 2.1 został usunięty z instalacji zestawu SDK w .NET 10. Zestawy SDK automatycznie pobierają brakujące pakiety docelowe przy użyciu pakietów NuGet podczas kompilowania aplikacji.

.NET zakresy funkcji zestawu SDK

W .NET Core 1.0 i 1.1 zestawy SDK używały schematu przechowywania wersji podobnego do runime. Ostatni zestaw SDK w wersji .NET Core 1.1 został w wersji 1.1.14 i zawierał środowisko uruchomieniowe 1.1.13.

Zespoły funkcji zestawu SDK zostały wprowadzone w zestawie SDK w wersji 2.1.100 w celu odróżnienia obsługiwanych funkcji w Visual Studio. Zestaw SDK dostarczany w ramach wersji .NET Core 2.0.5. Ostatni zestaw SDK 2.0 został w wersji 2.1.202 i dołączony do wersji 2.0.9. Pierwszy zestaw SDK do wysłania w wersji .NET Core 2.1 został w wersji 2.1.300. W kolejnych wersjach zespoły funkcji zestawu SDK zawsze zaczynają się od 100, np. 2.2.100, 3.0.100 itp.