Documentation sur les scripts dotnet-install

  • Article

Nom

dotnet-install.ps1 | dotnet-install.sh - Script utilisé pour installer le SDK .NET et le runtime partagé.

Synopsis

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

Comme le script bash lit également les commutateurs PowerShell, vous pouvez utiliser ces derniers avec le script sur les systèmes Linux/macOS.

Description

Les scripts dotnet-install effectuent une installation non administrateur du SDK .NET, qui inclut l’interface CLI .NET et le runtime partagé. Il existe deux scripts :

Notes

.NET collecte les données de télémétrie. Pour plus d’informations et sur la désactivation, consultez la télémétrie SDK .NET.

Objectif

L’utilisation prévue des scripts est destinée aux scénarios d’intégration continue (CI), où :

  • Le SDK doit être installé sans interaction utilisateur et sans droits d’administrateur.

  • L’installation du SDK n’a pas besoin de conserver plusieurs exécutions CI.

    Séquence classique d’événements :

    • CI est déclenché.
    • CI installe le SDK à l’aide de l’un de ces scripts.
    • CI termine son travail et efface les données temporaires, y compris l’installation du SDK.

Pour configurer un environnement de développement ou exécuter des applications, utilisez les programmes d’installation plutôt que ces scripts.

Nous vous recommandons d’utiliser la version stable des scripts :

La source des scripts se trouve dans le référentiel GitHub dotnet/install-scripts.

Comportement du script

Les deux scripts ont le même comportement. Ils téléchargent le fichier ZIP/tarball à partir des cibles de builds CLI, puis poursuivent l’installation dans l’emplacement par défaut ou dans un emplacement spécifié par -InstallDir|--install-dir.

Par défaut, les scripts d’installation téléchargent et installent le Kit de développement logiciel (SDK). Si vous souhaitez obtenir uniquement le runtime partagé, spécifiez l’argument -Runtime|--runtime.

Par défaut, le script ajoute l’emplacement d’installation $PATH pour la session active. Remplacez ce comportement par défaut en spécifiant l’argument -NoPath|--no-path. Le script ne définit pas la variable d’environnement DOTNET_ROOT.

Important

Le script n’ajoute pas l’emplacement d’installation à la variable d’environnement de PATH l’utilisateur. Vous devez l’ajouter manuellement.

Avant d’exécuter le script, installez les dépendances nécessaires.

Vous pouvez installer une version spécifique à l’aide de l’argument -Version|--version. La version doit être spécifiée en trois parties (par exemple, 2.1.0). Si la version n’est pas spécifiée, le script installe la version latest.

Les scripts d’installation ne mettent pas à jour le Registre sur Windows. Ils téléchargent simplement les fichiers binaires compressés et les copient dans un dossier. Si vous souhaitez que les valeurs de clé de Registre soient mises à jour, utilisez les programmes d’installation .NET.

Options

  • -Architecture|--architecture <ARCHITECTURE>

    Architecture des fichiers binaires .NET à installer. Les valeurs possibles sont <auto>, amd64, x64, x86, arm64, arm, s390x et ppc64le. La valeur par défaut est <auto>, qui représente l’architecture de système d’exploitation en cours d’exécution.

  • -AzureFeed|--azure-feed

    À usage interne uniquement. Permet d’utiliser un autre stockage pour télécharger les archives du SDK. Ce paramètre est utilisé uniquement si --no-cdn a la valeur false. Par défaut, il s’agit de https://dotnetcli.azureedge.net/dotnet.

  • -Channel|--channel <CHANNEL>

    Spécifie le canal source pour l’installation. Les valeurs possibles sont :

    • STS : la version la plus récente de STS (Standard Term Support).
    • LTS : la version la plus récente de LTS (Long Term Support).
    • Version en deux parties au format A.B représentant une version spécifique (par exemple, 3.1 ou 8.0).
    • Version en trois parties au format A.B.Cxx, représentant une version spécifique du SDK (par exemple, 8.0.1xx ou 8.0.2xx). Disponible depuis la version 5.0.

    Le paramètre version remplace le paramètre channel lorsqu’une version autre que latest est utilisée.

    La valeur par défaut est LTS. Pour plus d’informations sur les canaux de prise en charge de .NET, consultez la page Stratégie de prise en charge .NET.

  • -DryRun|--dry-run

    Si cette option est définie, le script n’effectue pas l’installation. Au lieu de cela, il affiche la ligne de commande à utiliser pour installer de manière cohérente la version actuellement demandée de l’interface CLI .NET. Par exemple, si vous spécifiez la version latest, elle affiche un lien avec la version spécifique, pour que cette commande puisse être utilisée de façon déterministe dans un script de génération. Elle affiche également l’emplacement du fichier binaire si vous préférez l’installer ou le télécharger vous-même.

  • -FeedCredential|--feed-credential

    Valeur utilisée comme chaîne de requête à ajouter au flux Azure. Elle permet de changer l’URL afin d’utiliser des comptes de stockage d’objets blob non publics.

  • --help

    Affiche l’aide pour le script. S’applique uniquement au script bash. Pour PowerShell, utilisez Get-Help ./dotnet-install.ps1.

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

    Spécifie le chemin d’accès de l’installation. S’il n’existe pas déjà, le répertoire est créé. La valeur par défaut est %LocalAppData%\Microsoft\dotnet sur Windows et $HOME/.dotnet sur Linux/macOS. Les fichiers binaires sont placés directement dans ce répertoire.

  • -JSonFile|--jsonfile <JSONFILE>

    Spécifie un chemin d’accès à un fichier global.json qui sera utilisé pour déterminer la version du SDK. Le fichier global.json doit avoir une valeur pour sdk:version.

  • -NoCdn|--no-cdn

    Désactive le téléchargement à partir d’Azure Content Delivery Network (CDN) et utilise directement le flux non mis en cache.

  • -NoPath|--no-path

    Si cette option est définie, le dossier d’installation n’est pas exporté dans le chemin de la session actuelle. Par défaut, le script modifie le chemin d’accès, ce qui rend l’interface CLI .NET disponible immédiatement après l’installation.

  • -ProxyAddress

    Si cette option est définie, le programme d’installation utilise le proxy pendant la création de demandes web. (Valide uniquement pour Windows.)

  • -ProxyBypassList <LIST_OF_URLS>

    S’il est défini avec ProxyAddress, fournit une liste d’URL séparées par des virgules qui contournent le proxy. (Valide uniquement pour Windows.)

  • -ProxyUseDefaultCredentials

    Si cette option est définie, le programme d’installation utilise les informations d’identification de l’utilisateur actuel lors de l’utilisation de l’adresse proxy. (Valide uniquement pour Windows.)

  • -Quality|--quality <QUALITY>

    Télécharge la dernière version de la qualité spécifiée dans le canal. Les valeurs possibles sont : daily, signed, validated, preview et GA. La plupart des utilisateurs doivent utiliser les qualités daily, preview ou GA.

    Les différentes valeurs de qualité signalent les différentes étapes du processus de mise en production du Kit de développement logiciel (SDK) ou du runtime installé.

    • daily: les versions les plus récentes du kit de développement logiciel (SDK) ou du runtime. Elles sont développées tous les jours et ne sont pas testés. Elles ne sont pas recommandées pour une utilisation en production mais peuvent souvent être utilisées pour tester des fonctionnalités ou des correctifs spécifiques immédiatement après leur fusion dans le produit. Ces builds proviennent du référentiel dotnet/installer. Par conséquent, si vous recherchez des correctifs provenant de dotnet/sdk, vous devez attendre que le code soit publié et fusionné du kit de développement logiciel (SDK) vers le programme d’installation, avant qu’il n’apparaisse dans une build quotidienne.
    • signed : les builds signées par Microsoft qui ne sont pas validées ou publiées publiquement. Les builds signées peuvent faire l’objet d’une validation, d’une version préliminaire et d’une disponibilité générale. Ce niveau de qualité n’est pas destiné à une utilisation publique.
    • validated : les builds sur lesquelles des tests internes ont été effectués mais qui ne sont pas encore publiées en préversion ou en disponibilité générale. Ce niveau de qualité n’est pas destiné à une utilisation publique.
    • preview : les versions publiques mensuelles de la prochaine version de .NET, destinées à une utilisation publique. Non recommandées pour la production. Destinées à permettre aux utilisateurs d’expérimenter et de tester la nouvelle version majeure avant la version principale.
    • GA: les versions finales stables du kit de développement logiciel (SDK) .NET et du runtime. Destinées à une utilisation publique ainsi qu’à la prise en charge de la production.

    L’option --quality fonctionne uniquement en combinaison avec --channel, mais ne s’applique pas aux canaux STS ni LTS, et elle est ignorée si l’un de ces canaux est utilisé.

    Pour une installation du Kit de développement logiciel (SDK), utilisez une valeur channel au format A.B ou A.B.Cxx. Pour une installation du runtime, utilisez channel dans le format A.B.

    N’utilisez pas les deux paramètres version et quality. Quand quality est spécifié, le script détermine la version appropriée par elle-même.

    Disponible depuis la version 5.0.

  • -Runtime|--runtime <RUNTIME>

    Installe uniquement le runtime partagé et non l’intégralité du SDK. Les valeurs possibles sont :

    • dotnet : le runtime partagé Microsoft.NETCore.App.
    • aspnetcore : le runtime partagé Microsoft.AspNetCore.App.
    • windowsdesktop Le runtime partagé Microsoft.WindowsDesktop.App.

  • --os <OPERATING_SYSTEM>

    Spécifie le système d’exploitation pour lequel les outils sont installés. Les valeurs possibles sont : osx, macos, linux, linux-musl, freebsd.

    Le paramètre est facultatif et doit être utilisé uniquement lorsqu’il est nécessaire de remplacer le système d’exploitation détecté par le script.

  • -SharedRuntime|--shared-runtime

    Notes

    Ce paramètre est obsolète et sera peut-être supprimé dans une future version du script. L'alternative recommandée est l’option -Runtime|--runtime.

    Installe uniquement les bits du runtime partagé et non l’intégralité du SDK. Cette option équivaut à spécifier -Runtime|--runtime dotnet.

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

    Ignore l’installation des fichiers sans version, notamment dotnet.exe, s’ils existent déjà.

  • -UncachedFeed|--uncached-feed

    À usage interne uniquement. Permet d’utiliser un autre stockage pour télécharger les archives du SDK. Ce paramètre est utilisé uniquement si --no-cdn a la valeur true.

  • -KeepZip|--keep-zip

    Si elle est définie, l’archive du Kit de développement logiciel (SDK) téléchargée est conservée après l’installation.

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

Si elle est définie, l’archive du Kit de développement logiciel (SDK) téléchargée est stockée sur le chemin d’accès spécifié.

  • -Verbose|--verbose

    Affiche les informations de diagnostic.

  • -Version|--version <VERSION>

    Représente une version spécifique. Les valeurs possibles sont :

    • latest : la dernière build sur le canal (utilisée avec l’option -Channel).
    • Version en trois parties au format X.Y.Z représentant une version spécifique ; remplace l’option -Channel. Par exemple : 2.0.0-preview2-006120.

    Si aucune valeur n’est spécifiée, -Version est définie par défaut sur latest.

Exemples

  • Installez la dernière version LTS (Long Term Support) à l’emplacement par défaut :

    Windows :

    ./dotnet-install.ps1 -Channel LTS

    Mac OS/Linux :

    ./dotnet-install.sh --channel LTS

  • Installez la dernière préversion du SDK 6.0.1xx à l’emplacement spécifié :

    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

  • Installez la version 6.0.0 du runtime partagé :

    Windows :

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

    Mac OS/Linux :

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

  • Obtenir le script et installer la version 6.0.2 derrière un proxy d’entreprise (Windows uniquement) :

    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;

  • Obtenir des exemples de script et d’installation de l’interface CLI .NET :

    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>

Définir des variables d’environnement

L’installation manuelle de .NET n’ajoute pas les variables d’environnement à l’échelle du système et fonctionne généralement uniquement pour la session dans laquelle .NET a été installé. Il y a deux variables d’environnement que vous devez définir pour votre système d’exploitation :

  • DOTNET_ROOT

    Cette variable est définie sur le dossier .NET sur lequel .NET a été installé, par $HOME/.dotnet exemple pour Linux et macOS, et $HOME\.dotnet dans PowerShell pour Windows.

  • PATH

    Cette variable doit inclure à la fois le dossier DOTNET_ROOT et le dossier .dotnet/tools de l’utilisateur. En règle générale, il s’agit de $HOME/.dotnet/tools sur Linux et macOS, et $HOME\.dotnet\tools dans PowerShell sur Windows.

Conseil

Pour Linux et macOS, utilisez la commande echo pour définir les variables dans votre profil shell, telles que .bashrc :

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

Désinstaller l’interface

Il n’existe aucun script de désinstallation. Pour obtenir des informations sur la désinstallation manuelle de .NET, consultez Procédure de suppression du runtime et du kit de développement logiciel (SDK) .NET.

Validation de signature de dotnet-install.sh

La validation de signature est une mesure de sécurité importante qui permet de vérifier l’authenticité et l’intégrité d’un script. En vérifiant la signature d’un script, vous pouvez veiller à ce qu’il n’ait pas été falsifié et qu’il provient d’une source approuvée.

Voici un guide pas à pas sur la façon de vérifier l’authenticité du script dotnet-install.sh en utilisant GPG :

  1. Installer GPG : GPG (GNU Privacy Guard) est un outil gratuit et open source pour chiffrer et signer des données. Vous pouvez l’installer en suivant les instructions du site web GPG.
  2. Importer notre clé publique : téléchargez le fichier de clé publique install-scripts, puis importez-le dans votre porte-clés GPG en exécutant la commande gpg --import dotnet-install.asc.
  3. Télécharger le fichier de signature : le fichier de signature de notre script Bash est disponible sur https://dot.net/v1/dotnet-install.sig. Vous pouvez le télécharger en utilisant un outil comme wget ou curl.
  4. Vérifier la signature : pour vérifier la signature de notre script Bash, exécutez la commande gpg --verify dotnet-install.sig dotnet-install.sh. Cette opération vérifie la signature du fichier dotnet-install.sh par rapport à la signature dans le fichier dotnet-install.sig.
  5. Vérifier le résultat : si la signature est valide, vous voyez un message contenant Good signature from "Microsoft DevUXTeamPrague <devuxteamprague@microsoft.com>". Cela indique que le script n’a pas été falsifié et peut être approuvé.

Préparation de l’environnement

L’installation de GPG et l’importation de notre clé publique est une opération unique.

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

En cas de réussite, vous devriez voir une sortie qui ressemble à ce qui suit :

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

Téléchargement et vérification

Une fois la clé importée, vous pouvez maintenant télécharger le script et la signature, puis vérifier que le script correspond à la signature :

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

En cas de réussite, vous devriez voir une sortie qui ressemble à ce qui suit :

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

L’avertissement signifie que vous n’approuvez pas la clé publique dans le porte-clés, mais que le script est toujours vérifié. Le code de sortie retourné par la commande de vérification doit être 0, ce qui indique une réussite.

Voir aussi