Dotnet-Installationsskripts Verweis

  • Artikel

name

dotnet-install.ps1 | dotnet-install.sh: Skript für die Installation des .NET SDK und der Shared Runtime

Übersicht

Windows:

dotnet-install.ps1 [-Architecture <ARCHITECTURE>] [-AzureFeed]
    [-Channel <CHANNEL>] [-DryRun] [-FeedCredential]
    [-InstallDir <DIRECTORY>] [-JSonFile <JSONFILE>]
    [-NoCdn] [-NoPath] [-ProxyAddress] [-ProxyBypassList <LIST_OF_URLS>]
    [-ProxyUseDefaultCredentials] [-Quality <QUALITY>] [-Runtime <RUNTIME>]
    [-SkipNonVersionedFiles] [-UncachedFeed] [-KeepZip] [-ZipPath <PATH>] [-Verbose]
    [-Version <VERSION>]

Get-Help ./dotnet-install.ps1

Linux/macOS:

dotnet-install.sh  [--architecture <ARCHITECTURE>] [--azure-feed]
    [--channel <CHANNEL>] [--dry-run] [--feed-credential]
    [--install-dir <DIRECTORY>] [--jsonfile <JSONFILE>]
    [--no-cdn] [--no-path] [--quality <QUALITY>]
    [--runtime <RUNTIME>] [--runtime-id <RID>]
    [--skip-non-versioned-files] [--uncached-feed] [--keep-zip] [--zip-path <PATH>] [--verbose]
    [--version <VERSION>]

dotnet-install.sh --help

Das Bash-Skript liest auch PowerShell-Schalter, sodass Sie PowerShell-Schalter mit dem Skript auf Linux/macOS-Systemen verwenden können.

Beschreibung

Die dotnet-install-Skripts führen eine Nicht-Administrator-Installation des .NET SDK durch, das die .NET-CLI und die Shared Runtime enthält. Es gibt zwei Skripts:

Hinweis

.NET sammelt Telemetriedaten. Weitere Informationen über die Sammlung von Telemetriedaten sowie darüber, wie diese deaktiviert wird, finden Sie unter .NET-SDK-Telemetrie.

Zweck

Diese Skripts sind für die Verwendung in Continuous Integration-Szenarios (CI) konzipiert, in denen Folgendes zutrifft:

  • Das SDK muss ohne Benutzerinteraktion und ohne Administratorrechte installiert werden.

  • Die SDK-Installation muss nicht für mehrere CI-Ausführungen beibehalten werden.

    Die typische Sequenz für Ereignisse lautet folgendermaßen:

    • Die CI wird ausgelöst.
    • Die CI installiert das SDK mithilfe eines dieser Skripts.
    • Die CI schließt ihre Aufgaben ab und bereinigt temporäre Daten einschließlich der SDK-Installation.

Verwenden Sie die Installationsprogramme anstatt dieser Skripts, um eine Entwicklungsumgebung einzurichten oder um Apps auszuführen.

Es wird empfohlen, die stabile Version der Skripts zu verwenden:

Die Quelle für die Skripts befindet sich im GitHub-Repository dotnet/install-scripts.

Skriptverhalten

Beide Skripts weisen das gleiche Verhalten auf. Sie laden die ZIP-/Tarball-Datei vom CLI-Build-Ablagespeicherort herunter und installieren sie entweder am Standardspeicherort oder an einem in -InstallDir|--install-dir angegebenen Speicherort.

In der Standardeinstellung laden die Installationsskripts das SDK herunter und installieren es. Wenn Sie nur die freigegebene Laufzeit abrufen möchten, geben Sie das -Runtime|--runtime-Argument an.

In der Standardeinstellung fügt das Skript den Installationsort dem $PATH für die aktuelle Sitzung hinzu. Überschreiben Sie dieses Standardverhalten, indem sie das -NoPath|--no-path-Argument angeben. Das Skript legt die Umgebungsvariable DOTNET_ROOT nicht fest.

Wichtig

Das Skript fügt den Installationsort nicht in die PATH-Umgebungsvariable des Benutzers ein; Sie müssen ihn manuell hinzufügen.

Bevor Sie das Skript ausführen, installieren Sie die erforderlichen Abhängigkeiten.

Installieren Sie eine bestimmte Version mithilfe des Arguments -Version|--version. Die Version muss als dreiteilige Versionsnummer (z. B. 2.1.0) angegeben werden. Wenn die Version nicht angegeben wird, installiert das Skript die latest-Version.

Die Installationsskripts aktualisieren die Registrierung unter Windows nicht. Sie laden nur die gezippten Binärdateien herunter und kopieren sie in einen Ordner. Wenn Sie möchten, dass die Registrierungsschlüsselwerte aktualisiert werden, verwenden Sie die .NET-Installer.

Optionen

  • -Architecture|--architecture <ARCHITECTURE>

    Architektur der zu installierenden .NET-Binärdateien. Mögliche Werte sind <auto>, amd64, x64, x86, arm64, arm, s390x und ppc64le. Der Standardwert ist <auto>, was die derzeit ausgeführte Betriebssystemarchitektur darstellt.

  • -AzureFeed|--azure-feed

    Nur zur internen Verwendung. Ermöglicht die Verwendung eines anderen Speichers zum Herunterladen von SDK-Archiven. Dieser Parameter wird nur verwendet, wenn „--no-cdn“ als „false“ festgelegt ist. Der Standardwert ist https://dotnetcli.azureedge.net/dotnet.

  • -Channel|--channel <CHANNEL>

    Gibt den Quellkanal für die Installation an. Mögliche Werte sind:

    • STS: Das neueste STS-Release (Support mit Standardlaufzeit)
    • LTS: Das neueste LTS-Release (langfristiger Support)
    • Zweiteilige Version im A.B-Format, das eine bestimmte Version darstellt (z. B. 3.1 oder 8.0).
    • Dreiteilige Version im A.B.Cxx-Format, die eine bestimmte SDK-Version darstellt (z. B. 8.0.1xx oder 8.0.2xx). Verfügbar seit Release 5.0.

    Der version-Parameter überschreibt den channel-Parameter, wenn eine andere Version als latest verwendet wird.

    Der Standardwert ist LTS. Weitere Informationen zu .NET-Supportkanälen finden Sie auf der Seite .NET-Supportrichtlinie.

  • -DryRun|--dry-run

    Wenn festgelegt, führt das Skript die Installation nicht aus. Es zeigt stattdessen an, welche Befehlszeile verwendet werden soll, um die derzeit erforderliche Version der .NET-CLI konsistent zu installieren. Wenn Sie z.B. Version latest angeben, wird eine Verbindung mit der bestimmten Version angezeigt, damit dieser Befehl deterministisch in einem Buildskript verwendet werden kann. Außerdem wird der Speicherort der Binärdatei angezeigt, wenn Sie sie selbst installieren oder herunterladen möchten.

  • -FeedCredential|--feed-credential

    Wird als Abfragezeichenfolge zum Anfügen an den Azure-Feed verwendet. Ermöglicht das Ändern der URL, um nicht öffentliche Blob Storage-Konten verwenden zu können.

  • --help

    Druckt Hilfe für das Skript aus. Gilt nur für das Bash-Skript. Verwenden Sie Get-Help ./dotnet-install.ps1 für PowerShell.

  • -InstallDir|--install-dir <DIRECTORY>

    Gibt den Installationspfad an. Das Verzeichnis wird erstellt, wenn es nicht vorhanden ist. Der Standardwert lautet %LocalAppData%\Microsoft\dotnet unter Windows und $HOME/.dotnet unter Linux/macOS. Binärdateien werden direkt im Verzeichnis platziert.

  • -JSonFile|--jsonfile <JSONFILE>

    Gibt einen Pfad zu einer global.json-Datei an, die zur Bestimmung der SDK-Version verwendet wird. Die Datei global.json muss einen Wert für sdk:version haben.

  • -NoCdn|--no-cdn

    Deaktiviert das Herunterladen aus dem Azure Content Delivery Network (CDN) und verwendet den nicht zwischengespeicherten Feed direkt.

  • -NoPath|--no-path

    Wenn festgelegt, wird der Installationsordner nicht in den Pfad für die aktuelle Sitzung exportiert. Standardmäßig ändert das Skript den Pfad (PATH), wodurch die .NET-CLI sofort nach der Installation zur Verfügung steht.

  • -ProxyAddress

    Wenn festgelegt, verwendet das Installationsprogramm den Proxy bei der Durchführung von Webanfragen. (Nur gültig für Windows)

  • -ProxyBypassList <LIST_OF_URLS>

    Wenn diese Einstellung mit ProxyAddressfestgelegt ist, wird eine Liste mit durch Trennzeichen getrennten URLs bereitstellt, die den Proxy umgehen. (Nur gültig für Windows)

  • -ProxyUseDefaultCredentials

    Wenn festgelegt, verwendet der Installer bei Verwendung der Proxyadresse die Anmeldeinformationen des aktuellen Benutzers. (Nur gültig für Windows)

  • -Quality|--quality <QUALITY>

    Lädt den neuesten Build der angegebenen Qualität im Kanal herunter. Mögliche Werte: daily, signed, validated, preview und GA. Die meisten Benutzer sollten die Qualitäten daily, preview oder GA verwenden.

    Die verschiedenen Qualitätswerte signalisieren unterschiedliche Phasen des Releaseprozesses des installierten SDK bzw. der installierten Runtime.

    • daily: Die neuesten Builds des SDK oder der Runtime. Sie werden jeden Tag erstellt und sind nicht getestet. Sie werden nicht für die Produktion empfohlen, können aber oft verwendet werden, um bestimmte Features oder Korrekturen zu testen, unmittelbar nachdem sie mit dem Produkt zusammengeführt wurden. Diese Builds stammen aus dem Repository dotnet/installer. Wenn Sie also nach Korrekturen in dotnet/sdk suchen, müssen Sie warten, bis der Code fließt und vom SDK mit dem Installationsprogramm zusammengeführt wird, bevor er in einem täglichen Build auftaucht.
    • signed: Von Microsoft signierte Builds, die weder überprüft noch für die Öffentlichkeit bestimmt sind. Signierte Builds sind Kandidaten für ein Validierungs-, Vorschau- und GA-Release (allgemeine Verfügbarkeit). Diese Qualitätsebene ist eigentlich nicht für die öffentliche Verwendung vorgesehen.
    • validated: Builds, die einige interne Tests durchgeführt haben, aber noch nicht als Vorschauversion veröffentlicht wurden oder allgemein verfügbar sind. Diese Qualitätsebene ist eigentlich nicht für die öffentliche Verwendung vorgesehen.
    • preview: Die monatlichen öffentlichen Releases der nächsten Version von .NET, die für die öffentliche Verwendung vorgesehen sind. Nicht für die Produktion empfohlen. Vorgesehen, um Benutzern das Experimentieren und Testen der neuen Hauptversion vor ihrer Veröffentlichung zu ermöglichen.
    • GA: Die endgültigen stabilen Releases des .NET SDK und der Runtime. Vorgesehen für die öffentliche Verwendung sowie Produktionsunterstützung.

    Die Option --quality funktioniert nur in Kombination mit --channel, gilt aber nicht für die Kanäle STS und LTS und wird ignoriert, wenn einer dieser Kanäle verwendet wird.

    Verwenden Sie für eine SDK-Installation den Wert channel im Format A.B oder A.B.Cxx. Verwenden Sie für eine Laufzeitinstallation channel im A.B-Format.

    Verwenden Sie die Parameter version und quality nicht gleichzeitig. Wenn quality angegeben ist, bestimmt das Skript die richtige Version selbst.

    Verfügbar seit Release 5.0.

  • -Runtime|--runtime <RUNTIME>

    Es wird nur die freigegebene Runtime installiert und nicht das gesamte SDK. Mögliche Werte sind:

    • dotnet: Die freigegebene Runtime von Microsoft.NETCore.App.
    • aspnetcore: Die freigegebene Runtime von Microsoft.AspNetCore.App.
    • windowsdesktop: Die freigegebene Runtime von Microsoft.WindowsDesktop.App.

  • --os <OPERATING_SYSTEM>

    Hiermit wird das Betriebssystem angegeben, für das die Tools installiert werden. Die folgenden Werte sind möglich: osx, macos, linux, linux-musl und freebsd.

    Der Parameter ist optional und sollte nur verwendet werden, wenn er für die Außerkraftsetzung des Betriebssystems erforderlich ist, das vom Skript erkannt wurde.

  • -SharedRuntime|--shared-runtime

    Hinweis

    Dieser Parameter ist veraltet und wird in einer zukünftigen Version des Skripts möglicherweise entfernt. Die empfohlene Alternative ist die -Runtime|--runtime-Option.

    Es werden nur die freigegebenen Runtimebestandteile installiert und nicht das gesamte SDK. Diese Option entspricht der Angabe von -Runtime|--runtime dotnet.

  • -SkipNonVersionedFiles|--skip-non-versioned-files

    Die Installation nicht versionierte Dateien, wie dotnet.exe, wird übersprungen, falls diese bereits vorhanden sind.

  • -UncachedFeed|--uncached-feed

    Nur zur internen Verwendung. Ermöglicht die Verwendung eines anderen Speichers zum Herunterladen von SDK-Archiven. Dieser Parameter wird nur verwendet, wenn „--no-cdn“ als „true“ festgelegt ist.

  • -KeepZip|--keep-zip

    Wird diese Option festgelegt, wird das heruntergeladene SDK-Archiv nach der Installation beibehalten.

  • -ZipPath|--zip-path <PATH>

Wird diese Option festgelegt, wird das heruntergeladene SDK-Archiv unter dem angegebenen Pfad gespeichert.

  • -Verbose|--verbose

    Es werden Diagnoseinformationen angezeigt.

  • -Version|--version <VERSION>

    Stellt eine bestimmte Buildversion dar. Mögliche Werte sind:

    • latest: Der neueste Build auf dem Kanal (mit der -Channel-Option verwendet).
    • Dreiteilige Version im X.Y.Z-Format, die eine bestimmte Buildversion darstellt; sie hat Vorrang vor der -Channel-Option. Beispiel: 2.0.0-preview2-006120.

    Wenn nichts angegeben ist, wird für -Version standardmäßig latest verwendet.

Beispiele

  • Installieren Sie die neueste langfristig unterstützte (Long-Term Supported, LTS) Version am Standardspeicherort:

    Windows:

    ./dotnet-install.ps1 -Channel LTS

    Mac OS/Linux:

    ./dotnet-install.sh --channel LTS

  • Installieren Sie die neueste Vorschauversion des SDK 6.0.1xx am angegebenen Speicherort:

    Windows:

    ./dotnet-install.ps1 -Channel 6.0.1xx -Quality preview -InstallDir C:\cli

    Mac OS/Linux:

    ./dotnet-install.sh --channel 6.0.1xx --quality preview --install-dir ~/cli

  • Installieren Sie Version 6.0.0 der Shared Runtime:

    Windows:

    ./dotnet-install.ps1 -Runtime dotnet -Version 6.0.0

    Mac OS/Linux:

    ./dotnet-install.sh --runtime dotnet --version 6.0.0

  • Rufen Sie das Skript ab, und installieren Sie Version 6.0.2 hinter einem Unternehmensproxy (nur Windows):

    Invoke-WebRequest 'https://dot.net/v1/dotnet-install.ps1' -Proxy $env:HTTP_PROXY -ProxyUseDefaultCredentials -OutFile 'dotnet-install.ps1';
./dotnet-install.ps1 -InstallDir '~/.dotnet' -Version '6.0.2' -Runtime 'dotnet' -ProxyAddress $env:HTTP_PROXY -ProxyUseDefaultCredentials;

  • Rufen Sie das Skript ab, und installieren Sie die einzeiligen Beispiele für die .NET-CLI:

    Windows:

    # Run a separate PowerShell process because the script calls exit, so it will end the current PowerShell session.
&powershell -NoProfile -ExecutionPolicy unrestricted -Command "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; &([scriptblock]::Create((Invoke-WebRequest -UseBasicParsing 'https://dot.net/v1/dotnet-install.ps1'))) <additional install-script args>"

    Mac OS/Linux:

    curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin <additional install-script args>

Festlegen von Umgebungsvariablen

Beim manuellen Installieren von .NET werden die Umgebungsvariablen nicht systemweit hinzugefügt, und in der Regel funktioniert dieses Verfahren nur für die Sitzung, in der .NET installiert wurde. Es gibt zwei Umgebungsvariablen, die Sie für Ihr Betriebssystem festlegen sollten:

  • DOTNET_ROOT

    Diese Variable ist auf den Ordner festgelegt, in dem .NET installiert wurde, z. B. $HOME/.dotnet für Linux und macOS und $HOME\.dotnet in PowerShell für Windows.

  • PATH

    Diese Variable sollte sowohl den Ordner DOTNET_ROOT als auch den .dotnet/tools-Ordner des Benutzers enthalten. Im Allgemeinen ist dies $HOME/.dotnet/tools unter Linux und macOS und $HOME\.dotnet\tools in PowerShell unter Windows.

Tipp

Verwenden Sie für Linux und macOS den Befehl echo, um die Variablen in Ihrem Shellprofil festzulegen, z. B. .bashrc:

echo 'export DOTNET_ROOT=$HOME/.dotnet' >> ~/.bashrc
echo 'export PATH=$PATH:$DOTNET_ROOT:$DOTNET_ROOT/tools' >> ~/.bashrc

Deinstallieren

Es gibt kein Deinstallationsskript. Weitere Informationen zur manuellen Deinstallation von .NET finden Sie unter Entfernen der .NET-Runtime und des SDK.

Signaturüberprüfung von dotnet-install.sh

Die Signaturüberprüfung ist eine wichtige Sicherheitsmaßnahme, die die Authentizität und Integrität eines Skripts gewährleistet. Indem Sie die Signatur eines Skripts überprüfen, können Sie sicher sein, dass es nicht manipuliert wurde und dass es von einer vertrauenswürdigen Quelle stammt.

Im Folgenden finden Sie eine schrittweise Anleitung zur Überprüfung der Authentizität des dotnet-install.sh-Skripts mithilfe von GPG:

  1. GPG installieren: GPG (GNU Privacy Guard) ist ein kostenloses Open-Source-Tool zum Verschlüsseln und Signieren von Daten. Sie können es installieren, indem Sie die Anweisungen auf der GPG-Website befolgen.
  2. Importieren Sie unseren öffentlichen Schlüssel: Laden Sie die Public Key-Datei der Installationsskripts herunter, und importieren Sie sie dann in Ihren GPG-Schlüsselbund, indem Sie den Befehl gpg --import dotnet-install.asc ausführen.
  3. Laden Sie die Signaturdatei herunter: Die Signaturdatei für unser Bash-Skript ist unter https://dot.net/v1/dotnet-install.sig verfügbar. Sie können sie mit einem Tool wie wget oder curl herunterladen.
  4. Überprüfen Sie die Signatur: Führen Sie den Befehl gpg --verify dotnet-install.sig dotnet-install.sh aus, um die Signatur unseres Bash-Skripts zu überprüfen. Dadurch wird die Signatur der dotnet-install.sh-Datei anhand der Signatur in der dotnet-install.sig-Datei überprüft.
  5. Überprüfen Sie das Ergebnis: Wenn die Signatur gültig ist, wird eine Meldung mit Good signature from "Microsoft DevUXTeamPrague <devuxteamprague@microsoft.com>" angezeigt. Dies bedeutet, dass das Skript nicht manipuliert wurde und vertrauenswürdig ist.

Vorbereiten der Umgebung

Die Installation von GPG und das Importieren unseres öffentlichen Schlüssels ist ein einmaliger Vorgang.

sudo apt install gpg
wget https://dot.net/v1/dotnet-install.asc
gpg --import dotnet-install.asc

Bei erfolgreicher Ausführung sollte folgende Ausgabe angezeigt werden:

gpg: directory '/home/<user>/.gnupg' created
gpg: keybox '/home/<user>/.gnupg/pubring.kbx' created
gpg: /home/<user>/.gnupg/trustdb.gpg: trustdb created
gpg: key B9CF1A51FC7D3ACF: public key "Microsoft DevUXTeamPrague <devuxteamprague@microsoft.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Herunterladen und Überprüfen

Nachdem der Schlüssel importiert wurde, können Sie nun das Skript und die Signatur herunterladen und dann überprüfen, ob das Skript mit der Signatur übereinstimmt:

wget https://dot.net/v1/dotnet-install.sh
wget https://dot.net/v1/dotnet-install.sig
gpg --verify dotnet-install.sig dotnet-install.sh

Bei erfolgreicher Ausführung sollte folgende Ausgabe angezeigt werden:

gpg: Signature made <datetime>
gpg:                using RSA key B9CF1A51FC7D3ACF
gpg: Good signature from "Microsoft DevUXTeamPrague <devuxteamprague@microsoft.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 2B93 0AB1 228D 11D5 D7F6  B6AC B9CF 1A51 FC7D 3ACF

Die Warnung bedeutet, dass Sie dem öffentlichen Schlüssel im Schlüsselbund nicht vertrauen, aber das Skript wurde dennoch überprüft. Der vom Überprüfungsbefehl zurückgegebene Exitcode sollte 0 sein, was Erfolg signalisiert.

Siehe auch