Hanterade .NET-installationer på Windows

Delvis borttagna .NET installationer är en vanlig orsak till att sårbarhetsgenomsökningsprogram som Microsoft Defender – hantering av säkerhetsrisker rapporterar en enhet. Att förstå hur .NET installationer fungerar kan hjälpa administratörer att undersöka rapporter och vidta åtgärder.

På Windows består .NET komponenter som runtime och SDK av flera MSI:er. Enskilda MSI:er distribueras inte direkt. I stället är de sammanlänkade för att skapa paket.

Hämtar .NET på Windows

  • Fristående paket (EXE) kan laddas ned från .NET webbplats.
  • WinGet tillhandahåller paket som innehåller de .NET paketen.
  • Underhållsuppdateringar distribuerar paketen via Microsoft Update med hjälp av automatiska uppdateringar, WSUS och Windows Update Catalog.
  • Oberoende programvaruleverantörer (ISV:er) kan omdistribuera .NET paket som en del av sin programvara.
  • OEM-tillverkare innehåller ibland förinstallerade kopior av .NET paket i fabriksavbildningarna av nya enheter.
  • Vissa Azure Marketplace-avbildningar av Windows innehåller förinstallerade kopior av paketen.
  • Tredjepartspakethanterare som Chocolatey distribuerar också de .NET paketen.
  • Företag packar ibland om paketen med egna paket för intern distribution.
  • Vissa .NET programvärdar kan också uppmana användare att ladda ned och installera saknade runtime-paket.

Visual Studio kan också användas för att hämta .NET och använder samma MSI:er som de fristående paketen.

Note

Det .NET SDK-paketet levererades med Visual Studio till 16.2. Från och med .NET Core 3.0 i Visual Studio 16.3 ersattes SDK-paketen med de enskilda .NET MSI:er.

Upgrades

.NET stöder uppgraderingar mellan korrigeringsversioner i en större/mindre version. .NET 8.0.7 uppgraderar tidigare versioner som 8.0.4 eller 8.0.0, inklusive förhandsversioner, men uppgraderar inte en tidigare större version som .NET 7.0. .NET SDK stöder uppgraderingar mellan korrigeringar i ett funktionsband. 8.0.100 SDK kan uppgraderas till 8.0.103, men 8.0.3xx SDK uppgraderar inte 1xx- eller 2xx-funktionsbanden.

Merparten av uppgraderingarna hanteras på paketnivå. Den tidigare versionen tas bara bort när den nya versionen har installerats. Det finns två undantag: den .NET värden och ASP.NET Core modulens MSI:er uppdateras på plats.

Från och med .NET 8 kan användarna skjuta upp borttagningen av den tidigare versionen av ett paket.

Samlingssammansättning och referensräkning

Paket består av flera MSI:er, varav vissa delas mellan flera paket.

.NET installationssammansättning

  • Runtime-paketet innehåller tre MSI:er som också levereras i skrivbordskörningen och SDK-paketen.
  • Skrivbordspaketet innehåller ytterligare en MSI som delas med SDK-paketet.
  • SDK innehåller ytterligare MSI:er som innehåller CLI, mallar och målpaket som används för att skapa och skapa .NET program.

Delade MSI:er hanteras med hjälp av referensräkning. Varje .NET MSI skapar en registernyckel som kallas providernyckel som gör att ett paket kan registrera sig som beroende. Om en MSI redan är installerad uppdaterar paketet endast registreringsinformationen. Paket avregistreras när de tas bort. De delade MSI:erna tas bara bort när det inte finns några registrerade beroenden.

Registerinformationen nedan är ett exempel på .NET värd-MSI-providernyckeln. Det finns fyra registrerade beroenden, inklusive 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

Enskilda MSI:er blir överblivna när beroenden förblir registrerade efter att ett paket har tagits bort, till exempel när avinstallationen avbryts.

Note

Visual Studio använder ett välkänt värde, VS.{AEF703B8-D2CC-4343-915C-F54A30B90937}, för att registrera sig som beroende. Det faktiska referensantalet bestäms genom att kontrollera installationsmanifestet för varje Visual Studio instans.

Distribuerade installationer i papperskorgen

Distributionslagerinstallationer refererar till kopior av .NET som inte är associerade med en MSI. Detta kan uppnås genom att köra installationsskripten som administratör och ställa in installationskatalogen på "Program Files\dotnet". Distribution av lagerplatser kan komplicera reparationen. Skannrar rapporterar sårbarheter, men administratörer hittar inte MSI:er att avinstallera. DNIM kan identifiera distributionslagerinstallationer.

Upptäckt

DNIM förlitar sig på ett antal heuristiker för att identifiera paket och MSI:er som är associerade med .NET. Det är viktigt att korrekt identifiera installationer för att åtgärda enheter som inte är klagomål.

Bundles

Paket identifieras med hjälp av deras visningsnamn och filinformation som lagras i registret. Ytterligare kontroller utförs på körbara filer för att säkerställa att de är giltiga installationsprogram. Denna informatio jämförs också med JSON-data .NET publicerar för varje version.

MSI-identifiering

DNIM utför en fullständig sökning mot installationskomponentdata som lagras i registret under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components för att identifiera .NET MSI:er.

Varje undernyckel representerar ett annat komponent-ID. Värdena under varje nyckel representerar produktkoder. Både komponent-ID:t och produktkoderna lagras som packade GUID:er. Exemplet nedan är av komponenten som är associerad med 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

Distribuerade installationer för lagerplats

Eftersom DNIM utför en fullständig sökning av installationskomponenter klassificeras alla filer som Program Files\dotnet inte är associerade med en MSI som distributionslagerinstallationer.

Classification

Felaktig klassificering av installationer kan leda till att du tar bort eller behåller fel installation, eventuellt bryter mot program eller lämnar enheter i ett icke-kompatibelt tillstånd.

När en produkt (till exempel NET 10) har identifierats kan ytterligare information som dess version (till exempel 10.0.4) och supportfasen (till exempel aktiv) fastställas. På så sätt kan administratörer skapa flexibla distributioner.

Installationer klassificeras ytterligare enligt deras .NET komponent (ASP.NET Core, SDK osv.), arkitektur och typ av installation (paket, MSI eller bin distribuerad).

Det finns några särskilda fall som är värda att nämna.

.NET Standard 2.1

För att säkerställa konsekvent beteende krävs installationer för att definiera produkt-, lanserings- och supportfasen. Målpaketet för .NET Standard 2.1 är en intressant utmaning. Den innehåller inte körbar kod och tillhandahåller endast referenssammansättningar för de API:er som definieras av standarden. Målpaketet levererades först som en del av .NET Core 3.0.100 SDK, men ingick i alla efterföljande SDK:er fram till .NET 10. Även om DNIM klassificerar versionen och produkten under .NET Core 3.0 rapporteras supportfasen alltid som aktiv eftersom den kan ingå i SDK:er som har aktivt stöd.

Note

Målpaketet .NET Standard 2.1 togs bort från SDK-installationen i .NET 10. SDK:er laddar automatiskt ned saknade målpaket med Hjälp av NuGet-paket när du skapar program.

.NET SDK-funktionsband

I .NET Core 1.0 och 1.1 använde SDK:er ett versionsschema som liknar runime. Den sista SDK:t i .NET Core 1.1 versionades som 1.1.14 och inkluderade 1.1.13-körningen.

SDK-funktionsband introducerades i 2.1.100 SDK för att skilja mellan funktioner som stöds i Visual Studio. SDK:t levererades som en del av .NET Core 2.0.5-versionen. Den senaste 2.0 SDK:t har version 2.1.202 och ingår i 2.0.9-versionen. Den första SDK som skickades i .NET Core 2.1 var version 2.1.300. I senare versioner börjar SDK-funktionsband alltid vid 100, t.ex. 2.2.100, 3.0.100 osv.