Funktionsweise von dotnetup

Hinweis

dotnetup befindet sich in der öffentlichen Vorschau. Die Features und das Verhalten können sich vor der allgemeinen Verfügbarkeit ändern.

dotnetup trennt das, was Sie anfordern, von den Dateien, die es installiert. Mit diesem Modell können mehrere Anforderungen eine .NET Installation gemeinsam nutzen und dotnetup dateien entfernen, die nicht mehr benötigt werden.

Installationsverzeichnisse

Ein .NET Installationsstamm ist ein Verzeichnis, das von dotnetup nachverfolgt wird. Ein Installationsverzeichnis hat:

  • Ein vollqualifizierter Verzeichnispfad.
  • Eine Architektur: x86, x64 oder arm64.
  • Keine oder mehrere Installationsspezifikationen, angegeben als channels.
  • Null oder mehrere konkrete Installationen.

Die aktuelle CLI wird für die Architektur des laufenden dotnetup-Prozesses installiert. Sie verfügt nicht über eine Option für die Architektur.

Der standardmäßig von dotnetup verwaltete .NET Installationsstamm ist das dotnet Unterverzeichnis des Dotnetup-Datenverzeichnisses:

Platform Standard-Installationsverzeichnis
Windows %LOCALAPPDATA%\dotnetup\dotnet
macOS ~/Library/Application Support/dotnetup/dotnet
Linux $XDG_DATA_HOME/dotnetup/dotnet, oder ~/.local/share/dotnetup/dotnet wenn XDG_DATA_HOME nicht festgelegt ist

Verwenden Sie --install-path, um einen anderen Installationsstamm auszuwählen. Ein expliziter Installationspfad hat Vorrang vor einem Pfad aus global.json, der Vorrang vor dem Standardinstallationsstamm hat.

dotnetupschreibt nicht in ein vom System verwaltetes .NET-Verzeichnis, z. B. Program Files\dotnet oder /usr/share/dotnet.

Komponenten

dotnetup verwaltet diese Komponententypen:

Component Laufzeitspezifikationsname Installierter Inhalt
.NET SDK Nicht anwendbar SDKs, Hosts, Laufzeiten, Zielpakete und zugehörige SDK-Inhalte
.NET-Laufzeit runtime Microsoft.NETCore.App Laufzeit
ASP.NET Core Laufzeit aspnetcore Microsoft.AspNetCore.App Laufzeit
Windows Desktop-Runtime windowsdesktop Microsoft.WindowsDesktop.AppRuntime unter Windows

Die ASP.NET Core Aliase aspnet und der Windows Desktopalias desktop werden in Laufzeitkomponentenspezifikationen akzeptiert.

Installationsspezifikationen

Eine Installationsspezifikation gibt eine Komponente und einen Kanal oder eine genaue Version an. Beispielsweise bedeutet eine SDK-Spezifikation für 10.0.1xx "das neueste SDK im Featureband 10.0.1xx beibehalten".

Weitere Informationen zu den verschiedenen Arten unterstützter Kanäle und Versionen finden Sie in Kanäle und Versionen.

Jede Spezifikation hat eine der folgenden Quellen:

  • Explicit: Sie haben den Kanal oder die Version in der Befehlszeile angegeben.
  • GlobalJson: dotnetup hat die SDK-Anforderung von einer global.json Datei abgeleitet.

All ist ein Deinstallationsfilter. Es wird nicht als Spezifikationsquelle gespeichert.

Eine exakte Version ist eine fixierte Spezifikation. Aktualisierungsbefehle bringen es nicht voran. Eine Kanalspezifikation kann bei einer Aktualisierung einer neueren Version zugeordnet werden.

Installationen und freigegebene Dateien

Eine Installation erfasst eine konkrete Komponentenversion und die von ihr verwendeten Unterkomponentenverzeichnisse. Zwei Spezifikationen können in dieselbe Installation aufgelöst werden.

Befehle zum Deinstallieren entfernen zunächst übereinstimmende Spezifikationen. Die Garbage Collection behält dann die neueste installierte Version bei, die jeder verbleibenden Spezifikation entspricht. Sie entfernt eine Installation und ihre nicht gemeinsam genutzten Unterkomponenten nur, wenn keine verbleibende Spezifikation sie benötigt.

Nachverfolgte und nicht nachverfolgte Installationen

Standardmäßig zeichnet ein Installationsbefehl seine Spezifikation und sein Ergebnis im Manifest auf. Eine nachverfolgte Installation kann von dotnetup aufgelistet, aktualisiert und entfernt werden.

Die --untracked Option installiert Dateien, ohne sie zu registrieren. dotnetup listet, aktualisiert oder entfernt diese Dateien nicht. Verwenden Sie diese Option nur, wenn ein anderer Prozess das Zielverzeichnis besitzt.

Um versehentliches Mischen zu verhindern, schlägt eine nachverfolgte Installation fehl, wenn das Ziel eine vorhandene .NET Installation enthält, die sich nicht im ausgewählten Manifest befindet. Wählen Sie ein anderes Verzeichnis aus, entfernen Sie die vorhandene Installation, oder verwenden Sie --untracked.

Zustandsdateien

Das dotnetup-Datenverzeichnis enthält die folgenden Statusdateien auf Benutzerebene:

Datei Purpose
dotnetup_manifest.json Verfolgt Installationsstammverzeichnisse, Installationsspezifikationen, Installationen und freigegebene Unterkomponenten.
dotnetup_manifest.json.sha256 Erkennt Änderungen an Manifestinhalten, die von dotnetup nicht geschrieben wurden.
dotnetup.config.json Speichert den .NET Zugriffsmodus und ob sich das dotnetup Verzeichnis auf PATH befindet.

Bearbeiten Sie diese Dateien nicht. Verwenden Sie die Befehle dotnetup install, update, uninstall und env, um den zugehörigen Zustand zu ändern.

Die Umgebungsvariable DOTNET_DOTNETUP_DATA_DIR ändert das Datenverzeichnis. Die --manifest-path Option ändert nur das Manifest, das von einem Befehl verwendet wird. Es ändert weder die Konfigurationsdatei noch das Standardinstallationsstammverzeichnis.

Parallele Vorgänge

Installations-, Update-, Deinstallations-, Auflisten- und Garbage-Collection-Workflows koordinieren den Zugriff auf den gemeinsamen Installationsstatus. Ein Befehl, der mehrere Abhängigkeiten akzeptiert, löst ihre Abhängigkeiten vor der Installation auf und kann sie gleichzeitig herunterladen. Manifeständerungen bleiben serialisiert.

Siehe auch

  • Zuletzt aktualisiert um