Shadow Copy Cache Hell

This post may be terse and may possibly contain profanity. I’ve just wasted nearly a day and a half before solving this problem.

Situation:
I have Project….Lets call it Project “P”. Big project, .NET 1.1. Nasty stuff at the best of times.
Project A has a dependency on an internal framework project (Dependency “D”).

For the last 2 days, whenever i try and run a unit test using NUnit/TestDriven/ReSharper, my tests are littered with failures like this:

    TestCase ‘ProjectP.Test.Data.Documents.MemberAuthentication_Tests.Can_Confirm_Registration’
    failed: System.TypeLoadException : Could not load type DependencyD.ISomeInterface from assembly DependencyD.Framework, Version=1.1.0.0, Culture=neutral, PublicKeyToken=8c4881879956f3a5.
    at ProjectP.Test.Utility.TestUtility_For_People..ctor()
    d:projectsClientProjectClient.websitetrunkProjectP.testingdatapeopleMemberAuthentication_Tests.cs(92,0): at ProjectP.Test.Data.Documents.MemberAuthentication_Tests.Can_Confirm_Registration()

After clearing my local temp and my c:windows temp, i was still getting this error.
After deleting all bin/obj directories in my project, i was still getting this error.
After deleting all known references to “DependencyD.dll” from my system, i was still getting this error.
After lots of googling, nothing turned up which would give me ANY indication that this was a problem.

To solve the problem, I attached the debugger to one of the tests as it ran and looked at the debug output window as it was loading each of the referenced assemblies…here’s what i saw:

    C:Documents and Settingsxerxes.battiwallaLocal SettingsApplication Dataassemblydl2GK3YAWO1.PD9R117AEJZ.3263cf8f4b19a0818d9_d632c801DependencyD.dll

wtf? WTF is that directory and why is my dll there? some different Googling and i found the answer. Shadow Copy Cache is a feature of ASP.NET it seems which is the cause of my problems. I wont go into detail about what SCC is, but in a few words, it’s a private copy of all your DLLs for ASP.NET to use so that you don’t get sharing violation problems when your website code is changed.

Deleting the SCC directory and all its contents suddenly make my tests pass, and the world seems brighter once more. I cant FU**ING believe that was the problem. So obscure, i’d never heard of it.

I hope that this entry gets indexed by the search crawlers….i was unlucky in finding anything about this problem by searching for things like “TestDriven TypeLoadException” or “Could not load type from assembly wrong version”, i just dont want the same thing to happen again (or to anyone else).

grrrr….

3 comments

  1. I’m running into the same issue running NUnit with Cruize Control .NET.

    My problem is CC.net doesnt allow me to pass the /noshadow option to NUnit, and NUnit requires the f***ing cache to be present. And of course the root of all evil, MSBuild.exe doesn’t cache the build files properly. All in all its a huge mind blast.

    Any suggestions greatly appreciated!

    Thanks!
    ~Kit

  2. Hi Kit,

    Sounds like you’re traveling far out of your way to do something which has been done thousands of times before.

    Our CC.NET projects call on NAnt tasks or FinalBuilder projects which are delegated the responsibility of doing the clean, prep, build, test and deploy of our code.

    CruiseControl is an excellent Continuous Integration system. It’s a shit build system. It suggest calling your NUnit testing from NAnt rather than directly from CC.NET. It provides you with a lot more flexibility, and there countless resources on the net about how to do exactly this.

    TBH, i haven’t encountered the Shadow Copy Cache problem in our integration server, only on development machines…..The NAnt/NUnit combination has worked perfectly for us.

    -xerx

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>