Fonctionnement de dotnetup

Note

dotnetup est disponible en préversion publique. Ses fonctionnalités et son comportement peuvent changer avant la disponibilité générale.

dotnetup sépare les éléments demandés des fichiers qu’il installe. Ce modèle permet à plusieurs applications de partager une installation .NET et permet à dotnetup de supprimer des fichiers qui ne sont plus nécessaires.

Racines d’installation

Une racine d'installation .NET est un répertoire qui est suivi par dotnetup. Une racine d’installation a :

  • Chemin d’accès complet au répertoire.
  • Une architecture : x86, x64 ou arm64.
  • Zéro ou plusieurs spécifications d’installation, indiquées sous la forme de channels.
  • Zéro, une ou plusieurs installations spécifiques.

Le CLI actuel s'installe pour l'architecture du processus dotnetup en cours d'exécution. Elle n’a pas d’option d’architecture.

La racine d’installation .NET gérée par dotnetup par défaut est le dotnet sous-répertoire du répertoire de données dotnetup :

Platform Racine d’installation par défaut
Windows %LOCALAPPDATA%\dotnetup\dotnet
macOS ~/Library/Application Support/dotnetup/dotnet
Linux $XDG_DATA_HOME/dotnetup/dotnet, ou ~/.local/share/dotnetup/dotnet quand XDG_DATA_HOME n’est pas défini

Utilisez --install-path pour sélectionner une autre racine d’installation. Un chemin d’installation explicite est prioritaire sur un chemin provenant de global.json, lui-même prioritaire sur la racine d’installation par défaut.

dotnetup n’écrit pas vers un répertoire .NET géré par le système, tel que Program Files\dotnet ou /usr/share/dotnet.

Composants

dotnetup gère ces types de composants :

Component Nom de la spécification du runtime Contenu installé
Kit de développement logiciel (SDK) .NET Sans objet KIT SDK, hôte, runtime, packs de ciblage et contenu du SDK associé
environnement d’exécution .NET runtime Runtime Microsoft.NETCore.App
Runtime ASP.NET Core aspnetcore Runtime Microsoft.AspNetCore.App
Runtime Windows Desktop windowsdesktop Microsoft.WindowsDesktop.Appruntime sur Windows

Les alias aspnet ASP.NET Core et l’alias desktop Windows Desktop sont acceptés dans les spécifications des composants d’exécution.

Spécifications d’installation

Une spécification d’installation enregistre un composant et un canal ou une version exacte. Par exemple, une spécification SDK pour 10.0.1xx signifie « conserver le dernier SDK dans la bande de fonctionnalités 10.0.1xx ».

Vous pouvez en savoir plus sur les différents types de canaux et versions pris en charge dans canaux et versions.

Chaque spécification a l’une de ces sources :

  • Explicit: vous avez fourni le canal ou la version sur la ligne de commande.
  • GlobalJson : dotnetup a dérivé l'exigence du SDK à partir d'un fichier global.json.

All est un filtre de désinstallation. Il n’est pas stocké en tant que source de spécification.

Une version précise est une spécification figée. Les commandes de mise à jour ne l’avancent pas. Une spécification de canal peut pointer vers une version plus récente pendant une mise à jour.

Installations et fichiers partagés

Une installation enregistre une version concrète du composant et les répertoires sous-composants qu’elle utilise. Deux spécifications peuvent correspondre à la même installation.

Les commandes de désinstallation suppriment d’abord les spécifications correspondantes. Le garbage collection conserve ensuite la version la plus récente installée qui correspond à chaque spécification restante. Il supprime une installation et ses sous-composants non partagés uniquement lorsqu’aucune spécification restante n’en a besoin.

Avant que l’état de désinstallation ne change, il avertit si une autre spécification conserve une installation demandée ou si le garbage collection supprime des installations supplémentaires. En mode interactif, ces avertissements nécessitent une confirmation. Pour plus d’informations, consultez le comportement de désinstallation du Kit de développement logiciel (SDK) et le comportement de désinstallation du runtime.

Installations suivies et non suivies

Par défaut, une commande d’installation enregistre sa spécification et son résultat dans le manifeste. Une installation suivie peut être répertoriée, mise à jour et supprimée par dotnetup.

L’option --untracked installe les fichiers sans les consigner. dotnetup ne répertorie pas, ne met pas à jour ni ne supprime ces fichiers. Utilisez cette option uniquement quand un autre processus possède le répertoire cible.

Pour éviter le mélange accidentel, une installation tracée échoue si la cible contient une installation .NET existante qui n’est pas dans le manifeste sélectionné. Sélectionnez un autre répertoire, supprimez l’installation existante ou utilisez --untracked.

Fichiers d’état

Le répertoire de données dotnetup contient les fichiers d’état au niveau de l’utilisateur suivants :

Fichier Purpose
dotnetup_manifest.json Effectue le suivi des racines d’installation, des spécifications d’installation, des installations et des sous-composants partagés.
dotnetup_manifest.json.sha256 Détecte les modifications apportées au contenu manifeste que dotnetup n’a pas écrit.
dotnetup.config.json Stocke le mode d’accès .NET, si le répertoire dotnetup se trouve sur PATH, et si les notifications de mise à jour sont activées.
update-checks/ Stocke les horodatages et les versions disponibles pour les vérifications de mise à jour dotnetup.

Ne modifiez pas ces fichiers. Utilisez les commandes dotnetup install, update, uninstall et env pour modifier l’état associé. Utilisez dotnetup self update --update-notifications <true|false> pour modifier le paramètre de notification sans mettre à jour l’exécutable.

La DOTNET_DOTNETUP_DATA_DIR variable d’environnement modifie le répertoire de données. L’option --manifest-path modifie uniquement le manifeste utilisé par une seule commande. Il ne modifie pas le fichier de configuration ou la racine d’installation par défaut.

Opérations simultanées

Les flux de travail d’installation, de mise à jour, de désinstallation, de listage et de garbage collection coordonnent l’accès à l’état d’installation partagé. Une commande qui accepte plusieurs spécifications les résout avant l’installation et peut les télécharger simultanément. Les modifications du manifeste restent sérialisées.

L’auto-mise à jour remplace l’exécutable dotnetup indépendamment de l’état d’installation de .NET. D’autres commandes peuvent échouer pendant que la mise à jour automatique détient ses verrous de coordination. Réessayez ces commandes une fois la mise à jour terminée. Pour plus d’informations, consultez dotnetup self update.

Voir aussi

  • Dernière mise à jour :