Wo die Gigabyte wirklich liegen
Die IDE selbst sitzt in C:\Program Files\Microsoft Visual Studio\2022\<Edition> — Community, Professional oder Enterprise — und dieser Ordner besteht fast vollständig aus Workload-Komponenten: Compiler, SDKs, MSBuild, Debugger. Daneben verwaltet der Visual Studio Installer in C:\Program Files (x86)\Microsoft Visual Studio\Installer alle Instanzen auf der Maschine — klein, aber kritisch. Der beängstigend wirkende Cache ist C:\ProgramData\Microsoft\VisualStudio\Packages, wo der Installer die heruntergeladenen Pakete sammelt: eine volle 2022er-Installation mit schweren Workloads parkt dort gern 10 bis 20 GB.
Darüber liegt die Benutzerebene: %LOCALAPPDATA%\Microsoft\VisualStudio\<version> birgt Caches wie ComponentModelCache und den MEF-Cache samt dem Secret-Store; %USERPROFILE%\.nuget\packages kann still größer werden als die IDE selbst; und jede Solution trägt einen .vs-Ordner mit IntelliSense-Datenbanken und Autosave. Das sind die einzigen Ordner im ganzen Gefüge, deren Leeren normale Wartung ist statt ein Reparaturszenario.
- C:\Program Files\Microsoft Visual Studio\2022\<Edition> — die IDE und ihre Workload-Komponenten, verwaltet nur vom Installer
- C:\Program Files (x86)\Microsoft Visual Studio\Installer — der Bootstrapper für alle Instanzen, rund 100 MB, niemals löschen
- C:\ProgramData\Microsoft\VisualStudio\Packages — der Download-Cache des Installers, auf den meisten Maschinen der größte Brocken
- %LOCALAPPDATA%\Microsoft\VisualStudio\<version> — Benutzer-Caches, gefahrlos zu leeren bei geschlossenem Visual Studio
- %USERPROFILE%\.nuget\packages — der globale NuGet-Cache, sauber geleert über dotnet nuget locals all --clear
- .vs in jeder Solution — IntelliSense- und Autosave-Caches, bedenkenlos löschbar bei geschlossener Solution
Ausmisten über den Installer, nicht über den Datei-Explorer
Das echte Platzsparen kommt vom Entfernen von Workloads, nicht von Ordnern. Visual Studio Installer öffnen, bei der Instanz auf Ändern klicken und abhaken, was nicht mehr benutzt wird: Game-Toolchains, Mobile-Workloads, Embedded-Toolsets und alte .NET-Targeting-Packs sind die üblichen Multi-Gigabyte-Verdächtigen. Eine komplette zweite Instanz zu deinstallieren — etwa ein altes 2019er neben dem 2022er — ist der größte Einzelgewinn, und der Installer erledigt das sauber in einem Durchlauf. Komponentenordner stattdessen von Hand zu löschen spart dieselben Gigabytes und macht aus einer reparierbaren Installation eine kaputte, denn der Installer führt Buch, was er wohin gelegt hat.
Am häufigsten wird nach dem Packages-Cache gefragt, und die ehrliche Antwort lautet: löschen geht, nichts bricht — aber sinnvoll ist es nicht. Ohne diese Pakete lädt der nächste Vorgang Ändern, Reparieren oder Aktualisieren alles erneut herunter, was auf einer langsamen Leitung mehr kostet als die gewonnene Platte. Die eine dokumentierte Ausnahme für verzweifelte Fälle ist InstallCleanup.exe mit dem Schalter -full aus dem Installer-Verzeichnis: Es entfernt alle Instanzen, den Installer und alle zwischengespeicherten Daten der Maschine. Das ist ein Reset-Knopf, keine Aufräumroutine — danach wird von Grund auf neu installiert.
Die Wartung, die wirklich Routine ist
Zwischen den Installer-Diäten halten drei Gewohnheiten eine Dev-Maschine schlank. Die Benutzer-Caches räumt man frei, wenn Visual Studio spinnt — Fehler bei Erweiterungen und ein defekter MEF-Cache sind die Klassiker —, und zwar mit geschlossener IDE. Den NuGet-Cache hält man mit gelegentlichem dotnet nuget locals all --clear ehrlich, und alte .vs-Ordner dürfen beim Archivieren einer Solution sterben: Sie werden beim ersten Öffnen neu gebaut, einmal langsamer und danach korrekt. Bootstrap- und Setup-Protokolle in %TEMP% von gescheiterten Installationen darf man immer löschen.
Nichts davon braucht einen Wochenrhythmus. Eine Dev-Maschine, auf der alle paar Monate die Workloads auditiert werden, nach jeder zweiten Visual-Studio-Version die alte Instanz verschwindet und der NuGet-Cache geleert wird, sobald das Restore zäh wird, bleibt im Griff — und kein einziger Schritt erfordert es, Komponentenordner in den Papierkorb zu ziehen.
Fragen und Antworten
Kann man den Visual-Studio-Ordner Packages in ProgramData löschen?
Technisch ja — nichts bricht, aber der nächste Vorgang Ändern, Reparieren oder Aktualisieren lädt die Pakete erneut herunter: Man tauscht Platte gegen Bandbreite und Wartezeit.
Warum belegt Visual Studio so viel Speicherplatz?
Workload-Komponenten, SDKs und mehrere Instanzen nebeneinander dominieren; der Dialog Ändern im Installer zeigt genau, welche Workloads die Gigabytes besitzen, und entfernt sie sauber.
Vor dem Kauf genau wissen, was enthalten ist.
Der einmalige 30-Minuten-Test umfasst Basisfunktionen. PRO-markierte Werkzeuge bleiben bis zur Aktivierung einer kostenpflichtigen Lizenz gesperrt.
Weiterlesen
Schreiben Sie uns: [email protected]