dotnetup-Umgebungskonfiguration

Hinweis

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

Dotnetup kann die Umgebung so konfigurieren, dass die von ihm installierten .NET SDKs und Runtimes verfügbar sind. Dazu legen Sie die folgenden Umgebungsvariablen fest:

• PATH: Macht den dotnet Befehl in der Befehlszeile verfügbar. Dev-Tools wie Visual Studio oder C# Dev Kit verwenden auch PATH, um .NET SDKs und Runtimes zu finden.
• DOTNET_ROOT: Teilt frameworkabhängigen ausführbaren Anwendungsdateien mit, wo eine .NET Installation und die freigegebenen Laufzeiten gefunden werden sollen.

Dotnetup unterstützt unterschiedliche Zugriffsmodi, die steuern, wo diese Umgebungsvariablen gesetzt werden. Sie können einen Zugriffsmodus im anfänglichen Dotnetup-Setup oder später mit dem dotnetup env Befehl auswählen.

Zugriffsmodus	Behavior
none	Ändert diese Umgebungsvariablen nicht. .NET mit dotnetup dotnet ausführen.
shell	Ändert das Shellprofil, um diese Umgebungsvariablen festzulegen. Von dieser Shell gestartete Prozesse verwenden die von dotnetup installierten .NET SDKs und Runtimes.
everywhere	Ändert das System PATH und legt die Umgebungsvariable auf Benutzerebene DOTNET_ROOT fest. Nur für Windows verfügbar.

Standardmäßig fügt sich dotnetup auch dem PATH hinzu, unabhängig von der Einstellung des Zugriffsmodus. Dies kann mit dotnetup env set --dotnetup-on-path <true|false> gesteuert werden.

Überlegungen zum Überall-Modus

Der Modus „Überall“ ist die Standardeinstellung unter Windows, sodass SDKs und Laufzeiten, die von dotnetup installiert werden, über Entwicklertools und aus Terminals, die cmd als Shell verwenden, zur Verfügung stehen. Es gibt jedoch einige Dinge zu beachten, in erster Linie hinsichtlich der Interaktion mit systemweiten Installationen des .NET SDK und der Runtime.

Systemweite Installationen von .NET befinden sich unter dem Ordner „Programme“. Sie können mit Installationsprogrammen installiert werden, die von der Downloadseite .NET heruntergeladen werden können. Visual Studio installiert das .NET SDK und die Runtime systemweit, und Installationsprogramme für frameworkabhängige Anwendungen können auch die .NET Runtime, von der sie abhängen, am systemweiten Speicherort installieren.

Im Modus überall überschreibt der benutzerlokale dotnetup-verwaltete .NET Installationsstamm den computerweiten .NET Installationsstamm. Dies bedeutet, dass .NET SDKs und Runtimes, die in Program Files installiert sind, nicht verfügbar sind. Projekte, die von diesen SDKs abhängen, können nicht erfolgreich erstellt werden, wenn kein passendes SDK installiert ist. Wenn eine übereinstimmende Laufzeit nicht installiert ist, können frameworkabhängige Anwendungen nicht gestartet werden, und es wird ein Fehler angezeigt, der besagt: "Sie müssen .NET installieren oder aktualisieren, um diese Anwendung auszuführen."

Um diese Fehlschläge zu vermeiden, bietet das anfängliche dotnetup-Setup die Möglichkeit, vorhandene .NET-SDK- und Runtime-Installationen des Systems zu migrieren. Sie können sie auch explizit migrieren, indem Sie dotnetup runtime install --migrate-from-system für SDKs oder dotnetup sdk install --migrate-from-system für Laufzeiten ausführen.

Das Aktivieren oder Deaktivieren des Modus "Überall" erfordert das Ändern des System-PATH, was Administratorrechte erfordert (z. B. die Bestätigung einer UAC-Eingabeaufforderung oder "Als Administrator ausführen"). Dies liegt daran, dass die systemweiten Installationsprogramme für .NET den .NET-Installationsstamm unter Program Files zum System-PATH hinzufügen, und der System-PATH hat Vorrang vor dem PATH auf Benutzerebene, wenn Befehle aufgelöst werden. Daher muss dotnetup den SystemPFAD ändern, damit der Dotnetup-.NET Installationsstamm Vorrang hat.

Da der SystemPFAD für alle Benutzer gilt, können sich diese Änderungen auf andere Benutzer auswirken. Der Pfad, der dem SystemPFAD hinzugefügt wird, befindet sich standardmäßig unter dem lokalen AppData-Ordner des Benutzers. Darauf können andere Benutzer normalerweise nicht zugreifen, daher würde dies nicht beeinflussen, welche Version von dotnet aufgelöst wird. Allerdings können Prozesse mit erhöhten Rechten (d. h. als Administrator ausgeführt) den Pfad lesen und könnten unerwartet .NET SDKs oder Runtimes von einem anderen Benutzer auflösen.

Unterstützte Shells

Unterstützung der Profil- und Skriptgenerierung:

• Bash
• Z shell
• Fisch
• Pwsh (PowerShell Core)
• PowerShell

Wenn Sie --shell nicht übergeben, erkennt dotnetup die aktuelle Shell. Verwenden Sie eine explizite Shell, wenn die Erkennung nicht verfügbar ist oder wenn Sie ein anderes Profil aktualisieren möchten:

dotnetup env set shell --shell zsh

Gespeicherter und beobachteter Zustand

dotnetup.config.json speichert den ausgewählten Zugriffsmodus und, ob dotnetup auf PATH aktiviert sein soll. dotnetup env show vergleicht diese Konfiguration mit dem aktuellen Profil und der aktuellen Umgebung. Es meldet eine Abweichung, wenn der beobachtete Zustand nicht übereinstimmt.

Die gespeicherte Konfiguration erneut anwenden, um die Abweichung zu korrigieren:

dotnetup env set

Aktuelles Terminal

Profil- und Windows-Umgebungsänderungen schreiben die Umgebung des aktuellen Prozesses nicht neu. Öffnen Sie ein neues Terminal, laden Sie das geänderte Profil, oder bewerten Sie das generierte Skript.

Für Bash oder Z Shell:

eval "$(dotnetup env script)"

Für PowerShell:

dotnetup env script --shell pwsh | Invoke-Expression

env script folgt der gespeicherten Konfiguration, wenn Sie keine Auswahloptionen übergeben. Verwenden Sie --dotnet, --dotnetupoder beides, um den generierten Inhalt auszuwählen.

Umgebungskonfiguration entfernen

Entfernen Sie alle Verkabelungen der verwalteten Umgebung:

dotnetup env clear

Dieser Befehl entspricht:

dotnetup env set none --dotnetup-on-path false

SdKs oder Laufzeiten werden nicht deinstalliert.