Gestion des packages globaux, du cache HTTP et des dossiers temporaires

Chaque fois que vous installez, mettez à jour ou restaurez un package, NuGet gère les packages et les informations de package dans plusieurs dossiers en dehors de la structure de votre projet :

En utilisant le dossier global-packages , NuGet évite généralement de télécharger des packages qui existent déjà sur l’ordinateur, améliorant les performances des opérations d’installation, de mise à jour et de restauration. Lors de l’utilisation de PackageReference, le dossier global-packages évite également de conserver les packages téléchargés dans les dossiers de projet, où ils peuvent être ajoutés par inadvertance au contrôle de code source et réduit l’impact global de NuGet sur le stockage informatique.

Lorsque vous êtes invité à récupérer un package, NuGet recherche d’abord dans le dossier global-packages . Si la version exacte du package n’est pas là, NuGet vérifie toutes les sources de package non HTTP. Si le package est toujours introuvable, NuGet recherche le package dans le http-cache , sauf si vous spécifiez --no-http-cache des dotnet.exe commandes ou -NoHttpCache des nuget.exe commandes. Si le package n’est pas dans le cache HTTP ou si le cache HTTP n’est pas utilisé, NuGet récupère le package via HTTP.

Pour plus d’informations, consultez Que se passe-t-il lorsqu’un package est installé ?.

paquets-globaux

Le dossier global-packages est l’emplacement où NuGet installe n’importe quel package téléchargé. Chaque paquet est entièrement décomposé dans un sous-dossier qui correspond à l’identificateur et au numéro de version du paquet. Les projets utilisant le format PackageReference utilisent toujours des packages directement à partir de ce dossier. Lorsque vous utilisez le packages.config, les packages sont installés dans le dossier global-packages , puis copiés dans le dossier du packages projet.

Nettoyage du répertoire global-packages

Le répertoire global-packages doit être nettoyé manuellement pour supprimer les packages qui ne sont plus utilisés. Pour ce faire, utilisez la dotnet nuget locals global-packages --clear commande ou le bouton « effacer les ressources locales NuGet » dans les options de Visual Studio (équivalent à dotnet nuget locals all --clear). Après avoir désactivé le répertoire global-packages, vous devez restaurer à nouveau vos projets pour télécharger à nouveau tous les packages requis. Dans Visual Studio, vous devrez peut-être recharger votre solution pour effacer le cache « à jour des restaurations » de NuGet, ou effectuer une restauration de ligne de commande (par exemple, dans la fenêtre de terminal de Visual Studio) avec msbuild -t:restore your.sln.

Pour nettoyer uniquement les packages inutilisés, il s’agit d’un processus en deux étapes. Tout d’abord, il existe un paramètre updatePackageLastAccessTimenuget.config qui doit être activé. Ce paramètre fera que NuGet mettra à jour le fichier .nupkg.metadata de chaque package lorsqu'il est utilisé lors d'une restauration. Lorsque la restauration s’exécute, mais qu’un projet est déjà à jour, les horodatages du package ne sont pas mis à jour. Par conséquent, si les entrées de restauration d’un projet ne changent pas pendant plusieurs semaines, les .nupkg.metadata fichiers n’ont pas leurs horodatages mis à jour. Le .nupkg.metadata fichier est le dernier fichier créé par NuGet lors du téléchargement et de l’extraction de packages lors d’une restauration ou d’une installation. Il s’agit du fichier que la restauration utilise pour vérifier si un package a été extrait avec succès.

Ensuite, utilisez un outil pour effectuer le nettoyage. Une fois le updatePackageLastAccessTime paramètre activé, nous vous recommandons d’attendre quelques jours pour vous assurer que tous les packages que vous utilisez ont régulièrement mis à jour leurs horodatages.

À ce stade, NuGet ne fournit pas d’outil ou de commande pour ce faire. Vous pouvez ajouter une 👍 réaction à ce problème GitHub pour signaler votre intérêt. Certains membres de la communauté ont créé leurs propres outils NuGet open source que vous pouvez rechercher.

Si vous allez écrire votre propre outil de nettoyage, il est important que le .nupkg.metadata fichier soit supprimé si l’un des autres fichiers de package est supprimé. Nous vous recommandons donc de supprimer d’abord ce fichier. Sinon, les projets référençant le package peuvent avoir un comportement inattendu. Si vous écrivez un outil de nettoyage dans .NET, envisagez d’utiliser ConcurrencyUtilities.ExecuteWithFileLocked[Async](..) à partir du package NuGet.Common, en passant le chemin nupkg complet du répertoire du package que vous allez supprimer comme clé, pour éviter de supprimer un package qui est en cours d'extraction par le processus de restauration en même temps. Le répertoire des packages globaux se trouve par programmation avec le package NuGet.Configuration. Utilisez Settings.LoadDefaultSettings(path) pour obtenir une instance ISettings (vous pouvez passer null en tant que chemin d’accès, ou passer un répertoire si vous souhaitez gérer des solutions avec un nuget.config qui redirige le répertoire global-packages), puis utilisez SettingsUtility.GetGlobalPackagesFolder(settings). Vous pouvez également exécuter dotnet nuget locals global-packages --list en tant que processus enfant et analyser la sortie.

http-cache

NuGet met en cache les copies de la plupart des communications de flux NuGet (à l’exception de la recherche), organisées en sous-dossiers pour chaque source de package. Les packages ne sont pas développés et les fichiers dont la date de dernière modification est antérieure à 30 minutes sont généralement considérés comme expirés.

La restauration packageReference met en cache la liste des versions qu’une source contient. Par conséquent, si une nouvelle version d’un package est publiée et que vous souhaitez l’utiliser plus rapidement que la période d’expiration du cache de 30 minutes, vous pouvez effacer le cache http pour forcer la restauration à rechercher une version plus récente plus rapidement.

intérimaire

Dossier dans lequel NuGet peut stocker des fichiers temporaires pendant ses différentes opérations.

Si plusieurs opérations NuGet sont effectuées en parallèle, par exemple une seule machine exécutant plusieurs agents CI, il est important que tous les processus partagent le même répertoire temporaire (NuGetScratch). NuGet utilise le répertoire temporaire pour coordonner l’accès interprocesseur aux répertoires http-cache et global-packages, à l’aide de verrous de système de fichiers. Si différents processus utilisent différents répertoires temporaires mais partagent le même répertoire global-packages ou http-cache, divers erreurs peuvent se produire lors de la tentative de restauration ou d’installation des paquets. NuGet n’utilise pas le verrouillage du système de fichiers pour coordonner la restauration des projets. Par conséquent, deux processus différents essayant de restaurer le même projet en même temps peuvent rencontrer des problèmes même lorsque vous utilisez le même NuGetScratch répertoire.

plug-in-cache

Dossier où NuGet stocke les résultats de la requête de revendications de l'opération. Pour plus d’informations, consultez les informations de référence sur les plug-ins multiplateformes .

Affichage des emplacements des dossiers

Vous pouvez afficher les emplacements de répertoire à l’aide de la commande dotnet nuget locals :

dotnet nuget locals all --list

Sortie classique (Windows ; « user1 » est le nom d’utilisateur actuel :

http-cache: C:\Users\user1\AppData\Local\NuGet\v3-cache
global-packages: C:\Users\user1\.nuget\packages\
temp: C:\Users\user1\AppData\Local\Temp\NuGetScratch
plugins-cache: C:\Users\user1\AppData\Local\NuGet\plugins-cache

Sortie classique (Mac ; « user1 » est le nom d’utilisateur actuel :

info : http-cache: /home/user1/.local/share/NuGet/v3-cache
info : global-packages: /home/user1/.nuget/packages/
info : temp: /tmp/NuGetScratch
info : plugins-cache: /home/user1/.local/share/NuGet/plugins-cache

Sortie classique (Linux ; « user1 » est le nom d’utilisateur actuel :

info : http-cache: /home/user1/.local/share/NuGet/v3-cache
info : global-packages: /home/user1/.nuget/packages/
info : temp: /tmp/NuGetScratchuser1
info : plugins-cache: /home/user1/.local/share/NuGet/plugins-cache

Pour afficher l’emplacement d’un dossier unique, utilisez http-cache, , global-packagestempou plugins-cache au lieu de all.

Vous pouvez également afficher des emplacements avec NuGet.exe avec la commande locals :

# Display locals for all directories: global-packages, http-cache, temp and plugins-cache
nuget locals all -list

Effacement des dossiers locaux

Command-line

Si vous rencontrez des problèmes d’installation de package ou si vous souhaitez vous assurer que vous installez des packages à partir d’une galerie distante, utilisez l’option locals --clear (dotnet.exe) ou locals -clear (nuget.exe), en spécifiant le dossier à effacer ou all pour effacer tous les dossiers :

# Clear the HTTP cache (use either command)
dotnet nuget locals http-cache --clear
nuget locals http-cache -clear

# Clear the global packages folder (use either command)
dotnet nuget locals global-packages --clear
nuget locals global-packages -clear

# Clear the temporary cache (use either command)
dotnet nuget locals temp --clear
nuget locals temp -clear

# Clear the plugins cache (use either command)
dotnet nuget locals plugins-cache --clear
nuget locals plugins-cache -clear

# Clear all caches (use either command)
dotnet nuget locals all --clear
nuget locals all -clear

Visual Studio

Visual Studio prend en charge le nettoyage de tous les dossiers locaux dans les options du « Gestionnaire de package NuGet » trouvées sous la commande Outils > Gestionnaire de package NuGet > Paramètres du Gestionnaire de package.

Dans la page Général, sélectionnez Effacer les ressources locales NuGet. Une fois démarrée, cette action ne peut pas être annulée. Une barre de progression s’affiche et contient l’état final de la commande.

La fenêtre sortie lors de la sélection d’Afficher la sortie dans « Gestionnaire de package » affiche des détails supplémentaires sur la commande Clear, y compris les messages d’erreur.

Pour plus d’informations, consultez Options NuGet dans Visual Studio.

Dépannage des erreurs

Les erreurs suivantes peuvent se produire lors de l’utilisation nuget locals ou dotnet nuget localsde :

• Erreur : le processus ne peut pas accéder au package< de fichiers>, car il est utilisé par un autre processus ou l’effacement des ressources locales a échoué : Impossible de supprimer un ou plusieurs fichiers

  Un ou plusieurs fichiers du dossier sont utilisés par un autre processus ; Par exemple, un projet Visual Studio est ouvert qui fait référence à des packages dans le dossier global-packages . Fermez ces processus et réessayez.

• Erreur : l’accès au chemin d’accès <> est refusé ou le répertoire n’est pas vide

  Vous n’êtes pas autorisé à supprimer des fichiers dans le cache. Modifiez les autorisations de dossier, le cas échéant, puis réessayez. Sinon, contactez votre administrateur système.

• Erreur : le chemin d’accès spécifié, le nom de fichier ou les deux sont trop longs. Le nom de fichier complet doit être inférieur à 260 caractères, et le nom du répertoire doit être inférieur à 248 caractères.

  Raccourcissez les noms de dossiers et réessayez.