Nettoyage de Visual Studio : cache de l'installeur et dossiers de composants

Où se cachent vraiment les gigaoctets

L'IDE elle-même siège dans C:\Program Files\Microsoft Visual Studio\2022\<Edition> — Community, Professional ou Enterprise — et ce dossier est presque entièrement fait de composants de charges de travail : compilateurs, SDK, MSBuild, débogueurs. À côté, le Visual Studio Installer occupe C:\Program Files (x86)\Microsoft Visual Studio\Installer : la pièce minuscule mais critique qui gère toutes les instances de la machine. Le cache inquiétant, c'est C:\ProgramData\Microsoft\VisualStudio\Packages, où l'installeur conserve les paquets téléchargés — une installation complète de 2022 avec des charges lourdes peut y parquer 10 à 20 Go.

Par-dessus vient la couche par utilisateur : %LOCALAPPDATA%\Microsoft\VisualStudio\<version> abrite des caches comme ComponentModelCache et le cache MEF plus le magasin de secrets ; %USERPROFILE%\.nuget\packages sait grossir en silence jusqu'à dépasser l'IDE elle-même ; et chaque solution traîne un dossier .vs avec ses bases IntelliSense et l'autosauvegarde. Ce sont les seuls dossiers de tout l'édifice où supprimer relève de la maintenance normale et non d'un scénario de réparation.

• C:\Program Files\Microsoft Visual Studio\2022\<Edition> — l'IDE et ses composants de charges de travail, gérés uniquement par l'installeur
• C:\Program Files (x86)\Microsoft Visual Studio\Installer — le programme qui gère toutes les instances, environ 100 Mo, à ne jamais supprimer
• C:\ProgramData\Microsoft\VisualStudio\Packages — le cache de téléchargements de l'installeur, le plus gros dossier de la plupart des installations
• %LOCALAPPDATA%\Microsoft\VisualStudio\<version> — caches utilisateur, vidables Visual Studio fermé
• %USERPROFILE%\.nuget\packages — le cache global NuGet, correctement vidé via dotnet nuget locals all --clear
• .vs dans chaque solution — caches IntelliSense et autosauvegarde, supprimables sans crainte solution fermée

Tailler par l'installeur, pas par l'Explorateur

Les vraies économies de place viennent du retrait de charges de travail, pas de dossiers. Ouvrez le Visual Studio Installer, cliquez Modifier sur votre instance et décochez ce qui n'est plus utilisé : chaînes d'outils de jeux, charges mobiles, ensembles embarqués et vieux targeting packs .NET sont les suspects multi-gigaoctets habituels. Désinstaller une seconde instance entière — un vieux 2019 à côté du 2022 — est le gain unique le plus gros disponible, et l'installeur le fait proprement en une passe. Supprimer des dossiers de composants à la main réalise la même économie de disque et transforme une installation réparable en installation cassée, car l'installeur tient la comptabilité de ce qu'il a posé où.

Le dossier Packages est celui qu'on demande, et la réponse honnête est : oui, on peut le supprimer, rien ne casse — mais on ne devrait pas. Sans ces paquets, la prochaine opération Modifier, Réparer ou Mettre à jour retélécharge tout ce dont elle a besoin, ce qui sur une ligne lente coûte plus de temps que la place gagnée. L'exception documentée pour les cas désespérés, c'est InstallCleanup.exe avec le commutateur -full depuis le répertoire de l'Installer : il supprime toutes les instances, l'installeur et toutes les données en cache de la machine. C'est un bouton reset, pas une routine de nettoyage — il faudra tout réinstaller derrière.

L'entretien qui est vraiment de la routine

Entre deux tailles passées à l'installeur, trois habitudes gardent une machine de dev au propre. Videz les caches utilisateur quand Visual Studio se met à dérailler — erreurs d'extensions et cache MEF cassé sont les classiques — en supprimant les sous-dossiers de cache, IDE fermée. Tenez le cache NuGet en respect avec un dotnet nuget locals all --clear de temps en temps, et laissez mourir les vieux .vs quand une solution part aux archives : ils se reconstruisent à la première ouverture, une fois plus lentement puis correctement. Les journaux d'amorçage et d'installation dans %TEMP% issus d'installations ratées se suppriment toujours sans risque.

Rien de tout cela ne réclame un rythme hebdomadaire. Une machine de développement dont on audite les charges tous les quelques mois, dont l'ancienne instance part après chaque deuxième version de Visual Studio et dont le cache NuGet se vide quand le restore traîne, reste sous contrôle — et aucune de ces étapes n'exige de traîner des dossiers de composants vers la Corbeille.

Questions et réponses

À lire ensuite