NuGet: Dont you mess with the Cache!

Caching ist prinzipiell cool. Allerdings kann ein Cache auch Probleme "kaschieren". Benötigt ein Projekt-Build ein Package schaut NuGet erst in seinen lokalen Package Cache und lädt es erst vom Server herunter wenn es dort nicht zu finden ist. Super Sache. Für Entwicklungs-Builds will man die Version nicht immer hochdrehen sondern verwendet stattdessen gemäß Semantic Versioning die sog. pre-release Syntax. Lokal ist das kein Problem, man weiss ja dass der lokale Package Cache nutzerspezifisch unter %LocalAppData%\NuGet\Cache zu finden ist. Also einfach Package-Datei aus dem Cache-Verzeichnis löschen und weiter geht's! Aber wo ist der Package Cache auf einem Build-Server?

Ein Build-Service wird typischerweise mit dem SYSTEM-Account ausgeführt. Da ist es nicht so einfach den lokalen Package-Cache zu finden, da

• Windows die Verzeichnisse versteckt (ja, auch wenn man "Versteckte Dateien anzeigen" eingestellt hat)
• und für SYSTEM das Nutzerverzeichnis prinzipiell ganz woanders liegt

StackOverflow und ProcMon waren meine Freunde sodass ich den Cache schließlich im Systemprofil unter
c:\Windows\SysWOW64\config\systemprofile\AppData\Local\NuGet\Cache
finden konnte.

Merke: Dazu die Kommandozeile (als Administrator) bemühen. Der Windows Explorer verweigert es diesen Ort anzuzeigen. Auch dir zeigt keine Unterverzeichnisse an, aber seid versichert - sie sind da, mit cd lässt sich hineinwechseln.

So klappt's dann auch mit meinem Nachbarn Jenkins. Vielleicht hilft die Info ja mal dem einen oder Anderen. Abschließend bleibt zu sagen: "Don't do this at home" - der hier beschriebene Workaround sollte nur ausnahmsweise verwendet werden. Der richtige Weg ist die Version hochzudrehen und/oder mit sog. Pre-Releases zu arbeiten.