Matthew ".NET 247" Reynolds

Matthew Reynolds... software development consultant, author, speaker and trainer

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...

Posted: Aug 11 2003, 05:29 PM by mjreynolds | with 9 comment(s)

Comments

Nick said:

I've had same problem, any seemingly the only solution was as to solve the debugging issue to delete the shadow copied files. That made the debugger load the right dlls with the right symbols.

My only real suspicion was that the assemblies chached were all signed but that's all. Still looking for a real answer...

Nick
# November 11, 2003 4:16 AM

Sylvain Demers said:

I have the same problem, and it adds the shadow copy when using .NET Reflector
# January 29, 2004 1:57 PM

vivek said:

=====

The Breakpoint will not currently be hit. No Symbols have been loaded for this document.



Criteria For Resolution:

=================

- Correctly be able to debug ASP.NET Web Applications on your Windows XP machine.



Cause:

======

- In IIS, the “Cache ISAPI Applications” CheckBox was not selected.



Resolution:

========

1) Open up the IIS Management Console (Start -> Run -> Type: inetmgr)

2) Right-click on the Default Web Site Tab and choose Properties.

3) Choose the Home Directory Tab.

4) In the Application Settings section, choose the Configuration Button.

5) Choose the Mappings Tab and ensure that the “Cache ISAPI Applications” checkbox is selected.

# February 2, 2004 10:46 AM

Matt said:

I have the same problem with the breakpoints, I went to IIS to try to check that Cache ISAPI box and it was already checked
# April 1, 2004 7:02 PM

Dominique Gratpain said:

When you have an error like that :
"The Breakpoint will not currently be hit. No Symbols have been loaded for this document. ",
it is because there is no file.pdb with the file.dll.
Be sure you have "generate debugging informations" in the properties of the project.
And be sure the two files (.pdb and .dll) are in the bin folder of your solution.
# April 18, 2004 1:35 PM

Cheng said:

I am currently having the above problem.

I was looking for the c:\documents and settings\<name>\local settings\application data\assembly folder in my directory. I couldn't find it and I still get the error.

The answer from Dominique Gratpain, I don't know where to set the generate debugging informations in the properties of the project.

I would be very grateful if anyone could help me!!!

Thanks,

Cheng
# June 9, 2004 12:00 AM

Cheng said:

I have found the "generate debugging informations" option in the properties. For my project, it was already set.

I appreciate if anyone of you have other suggestions which I can try.

Thanks.

Cheng
# June 9, 2004 5:09 PM

Craig said:

You can also turn off shadowcopy in nunit 2.4.3. It's on the Tools\Options menu

# August 31, 2007 9:32 AM

gehho said:

Had a similar problem here. However, clearing the shadow copy cache did not help. However, rebuilding _all_ test DLLs did.

NUnit somehow used an outdated base DLL which was referenced by multiple unit test assemblies. Since I had fixed unit test in only one test DLL, I always rebuilt only this DLL. NUnit reloaded this test DLL, but not the base DLL. Therefore, I always had problems. I could only make NUnit use the updated base DLL by rebuilding all test projects.

# December 30, 2011 10:03 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)