Beheerde .NET-installaties op Windows

Gedeeltelijk verwijderd .NET installaties zijn een veelvoorkomende reden waarom software voor het scannen van beveiligingsproblemen zoals Microsoft Defender Vulnerability Management een apparaat rapporteert. Inzicht in hoe .NET installaties werken, kan beheerders helpen bij het onderzoeken van rapporten en het uitvoeren van herstelacties.

Op Windows bestaan .NET onderdelen, zoals de runtime en SDK, uit meerdere MSA's. Afzonderlijke MSIS's worden niet rechtstreeks gedistribueerd. In plaats daarvan worden ze aan elkaar gekoppeld om bundels te maken.

.NET verkrijgen op Windows

• Zelfstandige bundels (EXE's) kunnen worden gedownload van de .NET website.
• WinGet biedt pakketten die de .NET bundels bevatten.
• Onderhoudsupdates distribueren de bundels via Microsoft Update met behulp van automatische updates, WSUS en de Windows Update-catalogus.
• Onafhankelijke softwareleveranciers (ISV's) kunnen .NET bundels opnieuw distribueren als onderdeel van hun software.
• OEM's bevatten soms vooraf geïnstalleerde kopieën van .NET bundels in de fabrieksinstallatiekopieën van nieuwe apparaten.
• Sommige Azure Marketplace-installatiekopieën van Windows bevatten vooraf geïnstalleerde kopieën van de bundels.
• Pakketbeheerders van derden zoals Chocolatey distribueren ook de .NET bundels.
• Ondernemingen verpakken de bundels soms opnieuw met eigen pakketten voor interne distributie.
• Sommige .NET toepassingshosts kunnen gebruikers ook omsturen om ontbrekende runtimebundels te downloaden en te installeren.

Visual Studio kan ook worden gebruikt om .NET te verkrijgen en dezelfde MSA's te gebruiken als de zelfstandige bundels.

Note

De .NET SDK-bundel wordt geleverd met Visual Studio tot 16.2. Vanaf .NET Core 3.0 in Visual Studio 16.3 zijn de SDK-bundels vervangen door de afzonderlijke .NET MSA's.

Upgrades

.NET ondersteunt upgrades tussen patchversies binnen een primaire/secundaire versie. .NET 8.0.7 voert een upgrade uit van eerdere versies zoals 8.0.4 of 8.0.0, inclusief voorlopige versies, maar zal geen upgrade uitvoeren voor een vorige primaire release, zoals .NET 7.0. De .NET SDK ondersteunt upgrades tussen patches binnen een functieband. De SDK 8.0.100 kan worden geüpgraded naar 8.0.103, maar de 8.0.3xx SDK werkt de functiebanden 1xx of 2xx niet bij.

Het merendeel van de upgrades wordt verwerkt op bundelniveau. De vorige versie wordt alleen verwijderd zodra de nieuwe versie is geïnstalleerd. Er zijn twee uitzonderingen: de .NET host en ASP.NET Core module-MSIs worden bijgewerkt.

Vanaf .NET 8 kunnen gebruikers de vorige versie van een bundel uitstellen.

Bundelsamenstelling en verwijzing tellen

Bundels zijn samengesteld uit meerdere MSA's, waarvan sommige worden gedeeld tussen meerdere bundels.

• De runtimebundel bevat drie MSA's die ook worden verzonden in de desktopruntime en SDK-bundels.
• De bureaubladbundel bevat een extra MSI die wordt gedeeld met de SDK-bundel.
• De SDK bevat aanvullende MSA's die de CLI, sjablonen en doelpakketten bevatten die worden gebruikt voor het maken en bouwen van .NET toepassingen.

Gedeelde MSA's worden beheerd met verwijzingstellingen. Elke .NET MSI maakt een registersleutel genaamd een providersleutel waarmee een bundel zichzelf kan registreren als afhankelijk. Als er al een MSI is geïnstalleerd, werkt de bundel alleen de registratiegegevens bij. Bundels worden niet geregistreerd wanneer ze worden verwijderd. De gedeelde MSA's worden slechts verwijderd zodra er geen geregistreerde afhankelijken zijn.

De onderstaande registergegevens zijn een voorbeeld van de .NET host-MSI-providersleutel. Er zijn vier geregistreerde afhankelijken, waaronder 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

Afzonderlijke MSIS's worden zwevend wanneer afhankelijken geregistreerd blijven nadat een bundel is verwijderd, bijvoorbeeld wanneer de verwijdering wordt onderbroken.

Note

Visual Studio een bekende waarde gebruikt om zichzelf als afhankelijke waarde VS.{AEF703B8-D2CC-4343-915C-F54A30B90937}te registreren. Het werkelijke aantal verwijzingen wordt bepaald door het installatiemanifest voor elk Visual Studio exemplaar te controleren.

Installaties die zijn geïmplementeerd in een bin

In de bin geïmplementeerde installaties verwijzen naar kopieën van .NET die niet zijn gekoppeld aan een MSI. Dit kan worden bereikt door de installatiescripts uit te voeren als beheerder en de installatiemap in te stellen op Program Files\dotnet. Installaties die in de bin zijn geïmplementeerd, kunnen het herstel bemoeilijken. Scanners melden beveiligingsproblemen, maar beheerders vinden geen MSIS's om te verwijderen. DNIM kan geïmplementeerde bin-installaties detecteren.

Opsporing

DNIM is afhankelijk van een aantal heuristieken om bundels en MSA's te identificeren die zijn gekoppeld aan .NET. Het nauwkeurig detecteren van installaties is van cruciaal belang voor het oplossen van apparaten die geen klacht indienen.

Bundles

Bundels worden geïdentificeerd met behulp van hun weergavenamen en bestandsinformatie die zijn opgeslagen in het register. Aanvullende controles worden uitgevoerd op uitvoerbare bestanden om ervoor te zorgen dat ze geldige installatieprogramma's zijn. Deze informatio wordt ook vergeleken met de JSON-gegevens .NET publiceert voor elke release.

MSI-detectie

DNIM voert een uitgebreide zoekopdracht uit op basis van de gegevens van het installatieonderdeel die in de registratie HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components zijn opgeslagen om .NET MSA's te identificeren.

Elke subsleutel vertegenwoordigt een andere onderdeel-id. De waarden onder elke sleutel vertegenwoordigen productcodes. Zowel de onderdeel-id als productcodes worden opgeslagen als verpakte GUID's. Het onderstaande voorbeeld is van het onderdeel dat is gekoppeld aan 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

Geïmplementeerde bin-installaties

Omdat DNIM een uitgebreide zoekopdracht uitvoert naar installatieonderdelen, worden bestanden die niet Program Files\dotnet aan een MSI zijn gekoppeld, geclassificeerd als installaties die in de bin zijn geïmplementeerd.

Classification

Onjuiste classificatie van installaties kan leiden tot het verwijderen of behouden van de verkeerde installatie, mogelijk brekende toepassingen of het verlaten van apparaten met een niet-compatibele status.

Zodra een product (bijvoorbeeld NET 10) is geïdentificeerd, kunnen aanvullende informatie zoals de release (bijvoorbeeld 10.0.4) en de ondersteuningsfase (bijvoorbeeld actief) worden bepaald. Hierdoor kunnen beheerders flexibele implementaties maken.

Installaties worden verder geclassificeerd op basis van hun .NET-onderdeel (ASP.NET Core, SDK, enzovoort), architectuur en type installatie (bundel, MSI of bin geïmplementeerd).

Er zijn enkele speciale gevallen die het vermelden waard zijn.

.NET Standard 2.1

Om consistent gedrag te garanderen, moeten installaties hun product-, release- en ondersteuningsfase definiëren. Het doelpakket voor .NET Standard 2.1 biedt een interessante uitdaging. Het bevat geen uitvoerbare code en biedt alleen referentieassembly's voor de API's die door de standaard zijn gedefinieerd. Het doelpakket werd eerst geleverd als onderdeel van de .NET Core 3.0.100 SDK, maar werd opgenomen in elke volgende SDK tot .NET 10. Hoewel DNIM de release en het product onder .NET Core 3.0 classificeert, wordt de ondersteuningsfase altijd als actief gerapporteerd omdat deze kan worden opgenomen in SDK's die actief zijn.

Note

Het .NET Standard 2.1-doelpakket is verwijderd uit de SDK-installatie in .NET 10. SDK's downloaden automatisch ontbrekende doelpakketten met behulp van NuGet-pakketten bij het bouwen van toepassingen.

.NET SDK-functiebanden

In .NET Core 1.0 en 1.1 hebben SDK's een versiebeheerschema gebruikt dat vergelijkbaar is met de runime. De laatste SDK in .NET Core 1.1 is versie 1.1.14 en bevat de runtime 1.1.13.

SDK-functies zijn geïntroduceerd in de SDK 2.1.100 SDK om onderscheid te maken tussen ondersteunde functies in Visual Studio. De SDK is geleverd als onderdeel van de .NET Core 2.0.5-release. De laatste 2.0 SDK is versie 2.1.202 en opgenomen in de release 2.0.9. De eerste SDK voor verzending in .NET Core 2.1 is versie 2.1.300. In latere releases beginnen SDK-functiebanden altijd bij 100, bijvoorbeeld 2.2.100, 3.0.100, enzovoort.