Verwaltete .NET Installationen auf Windows

Teilweise entfernte .NET Installationen sind ein häufiger Grund, warum Sicherheitsrisikoüberprüfungssoftware wie Microsoft Defender Vulnerability Management ein Gerät melden wird. Wenn Sie wissen, wie .NET Installationen funktionieren, können Administratoren dabei helfen, Berichte zu untersuchen und Abhilfemaßnahmen zu ergreifen.

Bei Windows bestehen .NET Komponenten wie Laufzeit und SDK aus mehreren MSIs. Einzelne MSIs werden nicht direkt verteilt. Stattdessen werden sie verkettet, um Bündel zu erstellen.

Erwerb von .NET auf Windows

• Eigenständige Bundles (EXEs) können von der .NET-Website heruntergeladen werden.
• WinGet stellt Pakete bereit, die die .NET Bundles enthalten.
• Wartungsupdates verteilen die Bündel über Microsoft Update mithilfe von automatischen Updates, WSUS und dem Windows Update-Katalog.
• Unabhängige Softwareanbieter (ISVs) können .NET Bundles als Teil ihrer Software neu verteilen.
• OEMs enthalten manchmal vorinstallierte Kopien von .NET Bundles in den Factoryimages neuer Geräte.
• Einige Azure Marketplace-Images von Windows enthalten vorinstallierte Kopien der Bundles.
• Paketmanager von Drittanbietern wie Chocolatey verteilen auch die .NET Bundles.
• Unternehmen packen die Pakete manchmal mit proprietären Paketen für die interne Verteilung um.
• Einige .NET Anwendungshosts können auch Benutzer zum Herunterladen und Installieren fehlender Laufzeitbundle leiten.

Visual Studio können auch verwendet werden, um .NET zu erwerben und dieselben MSIs wie die eigenständigen Bündel zu verwenden.

Note

Das .NET SDK-Bündel wurde bis 16.2 mit Visual Studio ausgeliefert. Ab .NET Core 3.0 in Visual Studio 16.3 wurden die SDK-Bündel durch die einzelnen .NET MSIs ersetzt.

Upgrades

.NET unterstützt Upgrades zwischen Patchversionen innerhalb einer Haupt-/Nebenversion. .NET 8.0.7 aktualisiert frühere Versionen wie 8.0.4 oder 8.0.0, einschließlich Vorabversionen, führt jedoch kein Upgrade einer vorherigen Hauptversion wie .NET 7.0 durch. Das .NET SDK unterstützt Upgrades zwischen Patches innerhalb eines Featurebands. Das SDK 8.0.100 kann auf 8.0.103 aktualisiert werden, das 8.0.3xx SDK aktualisiert jedoch nicht die 1xx- oder 2xx-Featurebänder.

Die meisten Upgrades werden auf Bündelebene behandelt. Die vorherige Version wird nur entfernt, nachdem die neue Version installiert wurde. Es gibt zwei Ausnahmen: der .NET Host und ASP.NET Core Modul-MSIs werden aktualisiert.

Ab .NET 8 haben Benutzer die Möglichkeit, das Entfernen der vorherigen Version eines Bündels zurückzuweisen.

Bündelkomposition und Referenzzählung

Bündel bestehen aus mehreren MSIs, von denen einige zwischen mehreren Bündeln gemeinsam verwendet werden.

• Das Laufzeitbundle enthält drei MSIs, die auch in den Desktop-Runtime- und SDK-Bundles ausgeliefert werden.
• Das Desktoppaket enthält eine zusätzliche MSI,die für das SDK-Bundle freigegeben wird.
• Das SDK enthält zusätzliche MSIs, die die CLI, Vorlagen und Zielpakete enthalten, die zum Erstellen und Erstellen von .NET Anwendungen verwendet werden.

Freigegebene MSIs werden mithilfe der Verweiszählung verwaltet. Jedes .NET MSI erstellt einen Registrierungsschlüssel namens Anbieterschlüssel, mit dem sich ein Bündel selbst als abhängig registrieren kann. Wenn bereits eine MSI-Datei installiert ist, aktualisiert das Bundle nur die Registrierungsinformationen. Die Registrierung von Bundles wird aufgehoben, wenn sie entfernt werden. Die freigegebenen MSIs werden nur entfernt, wenn keine registrierten Nachfolger vorhanden sind.

Die folgenden Registrierungsinformationen sind ein Beispiel für den .NET Host-MSI-Anbieterschlüssel. Es gibt vier registrierte Abhängige, einschließlich 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

Einzelne MSIs werden verwaist, wenn abhängige Personen nach dem Entfernen eines Bündels registriert bleiben, z. B. wenn die Deinstallation unterbrochen wird.

Note

Visual Studio verwendet einen bekannten Wert, VS.{AEF703B8-D2CC-4343-915C-F54A30B90937}um sich selbst als abhängig zu registrieren. Die tatsächliche Referenzanzahl wird durch Überprüfen des Installationsmanifests für jede Visual Studio Instanz bestimmt.

Bereitgestellte Bin-Installationen

Bereitgestellte Bin-Installationen beziehen sich auf Kopien von .NET, die keiner MSI-Datei zugeordnet sind. Dies kann erreicht werden, indem sie die Installationsskripts als Administrator ausführen und das Installationsverzeichnis auf "Programme\dotnet" festlegen. Bereitgestellte Bin-Installationen können die Behebung erschweren. Scanner melden Sicherheitsrisiken, Administratoren finden jedoch keine MSIs, die deinstalliert werden sollen. DNIM kann bereitgestellte Bin-Installationen erkennen.

Detection

DNIM basiert auf einer Reihe von Heuristiken, um Bündel und MSIs zu identifizieren, die mit .NET verknüpft sind. Die genaue Erkennung von Installationen ist wichtig, um eine nicht beanstandete Geräte erfolgreich zu beheben.

Pakete

Bündel werden anhand ihrer Anzeigenamen und Dateiinformationen identifiziert, die in der Registrierung gespeichert sind. Zusätzliche Überprüfungen werden für ausführbare Dateien ausgeführt, um sicherzustellen, dass sie gültige Installer sind. Diese Informatio wird auch mit den JSON-Daten verglichen, .NET für jede Version veröffentlicht.

MSI-Erkennung

DNIM führt eine vollständige Suche nach den im Register HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components gespeicherten Installationskomponentendaten durch, um .NET MSIs zu identifizieren.

Jeder Unterschlüssel stellt eine andere Komponenten-ID dar. Die Werte unter den einzelnen Schlüsseln stellen Produktcodes dar. Sowohl die Komponenten-ID als auch die Produktcodes werden als verpackte GUIDs gespeichert. Das folgende Beispiel ist der Komponente dotnet.exezugeordnet.

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

Bereitgestellte Bin-Installationen

Da DNIM eine vollständige Suche nach Installationsprogrammkomponenten durchführt, werden alle Dateien, Program Files\dotnet die keiner MSI zugeordnet sind, als bereitgestellte Bin-Installationen klassifiziert.

Classification

Falsche Klassifizierung von Installationen kann dazu führen, dass die falsche Installation entfernt oder beibehalten wird, möglicherweise Anwendungen unterbrechen oder Geräte in einem nicht kompatiblen Zustand verlassen.

Sobald ein Produkt (z. B. NET 10) identifiziert wurde, können zusätzliche Informationen wie die Veröffentlichung (z. B. 10.0.4) und die Supportphase (z. B. aktiv) ermittelt werden. Auf diese Weise können Administratoren flexible Bereitstellungen erstellen.

Installationen werden nach ihrer .NET Komponente (ASP.NET Core, SDK usw.), Architektur und Installationstyp (Bundle, MSI oder bin bereitgestellt) weiter klassifiziert.

Es gibt einige spezielle Fälle, die erwähnt werden sollen.

.NET Standard 2.1

Zur Sicherstellung eines konsistenten Verhaltens müssen Installationen ihre Produkt-, Release- und Supportphase definieren. Das Zielpaket für .NET Standard 2.1 stellt eine interessante Herausforderung dar. Sie enthält keinen ausführbaren Code und stellt nur Referenzassemblys für die durch den Standard definierten APIs bereit. Das Zielpaket wurde zunächst als Teil des .NET Core 3.0.100 SDK ausgeliefert, wurde aber in allen nachfolgenden SDKs bis .NET 10 enthalten. Während DNIM die Version und das Produkt unter .NET Core 3.0 klassifizieren, wird die Supportphase immer als aktiv gemeldet, da sie in SDKs enthalten sein kann, die in der aktiven Unterstützung enthalten sind.

Note

Das .NET Standard 2.1-Zielpaket wurde aus der SDK-Installation in .NET 10 entfernt. SDKs laden beim Erstellen von Anwendungen automatisch fehlende Zielpakete mithilfe von NuGet-Paketen herunter.

.NET SDK-Featurebänder

In .NET Core 1.0 und 1.1 verwendeten SDKs ein Versionsverwaltungsschema, das der Runime ähnelt. Das letzte SDK in .NET Core 1.1 wurde als Version 1.1.14 versioniert und enthielt die 1.1.13-Laufzeit.

SDK-Featuresbands wurden im 2.1.100 SDK eingeführt, um zwischen unterstützten Features in Visual Studio zu unterscheiden. Das SDK wurde als Teil der .NET Core 2.0.5-Version ausgeliefert. Das letzte 2.0 SDK wurde als 2.1.202 versioniert und in der Version 2.0.9 enthalten. Das erste SDK, das in .NET Core 2.1 ausgeliefert werden soll, wurde als Version 2.1.300 versioniert. In späteren Versionen beginnen SDK-Featurebänder immer bei 100, z. B. 2.2.100, 3.0.100 usw.