Shadow copy cache "causes" weird debugging problems
(I am trying not to rant and rave about this - this just causes me a serious headache!)
This is one of these weird debugging issues - hopefully it will save some of you out there some time. About an hour ago, any of my changes to one of my application assemblies just didn't seem to be “sticking”. I was making changes and nothing appeared to be happening! Moreover, when I tried debugging the thing in VS .NET, any breakpoints I set would appear to set (no question mark in the little red dot), but VS .NET would just ignore any set breakpoints and skip over any calls into the assembly.
The solution? For some reason, the assembly had managed to get itself stored in the shadow copy cache. I am clueless as to why (maybe someone can enlighten me), but here's the diagnosis and solution for those who's experienced this problem.
First off, take a look in the Output window as VS .NET is running your app. Trace information is written out on assembly load so you can see what the debugger is attaching to. Here's some lines:
'Bs.Core.Host.exe': Loaded 'c:\work\xxx\bs.core\bs.core.host\bin\debug\bs.core.dll', Symbols loaded.
'Bs.Core.Client': Loaded 'C:\Work\xxx\Bs.Core\Bs.Core.Client\bin\Debug\Bs.Core.Client.exe', Symbols loaded.
'Bs.Core.Client.exe': Loaded 'c:\work\xxx\bs.core\bs.core.client\bin\debug\bs.core.dll', Symbols loaded.
'Bs.Core.Host.exe': Loaded 'c:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll', No symbols loaded.
'Bs.Core.Client.exe': Loaded 'c:\documents and settings\matthew\local settings\application data\assembly\dl2\a21peep8.8yn\d2rhz2m1.a4c\abec0abb\2043775d_2060c301\bs.core.desktop.dll', No symbols
The first three lines are making sense - the assemblies are comign out of the bin\debug folders and has “symbols laaded“. The last one isn't - it's been copied into the SCC somehow.
My solution (and I say *my* solution becuase this may cause problems), was to delete the entire shadow copy cache at c:\documents and settings\matthew\local settings\application data\assembly.
Update: I've just remembered that I was using Reflector to examine the resources in the assembly immediately before having this problem. This might have been what did it...