tags:

views:

1485

answers:

3

I'm using the NUnit GUI version, and it started to get upset at me when I have a test project loaded in there trying to test things. If I make a change in Visual Studio, and then try to rebuild the solution, it throws the error "Unable to copy file obj\Debug\foo.dll to bin\Debug\foo.dll. The process cannot access the file bin\Debug\foo.dll because it is being used by another process."

This is the DLL I have loaded into the GUI, of course. It used to be OK, and just refresh the project reference after a build, but now it seems to be blocking it. How can I get back to that behavior?

I've tried enabling/disabling the shadow copy setting by the way, with the same results either way.

VS2008 SP1 and NUnit 2.4.8, if that matters.

+1  A: 

I had this problem too, but I'm strugling to reproduce it today. The forums seem to suggest that it is due to your code not giving back resources that it was using. This rings a bell as I would have been testing an Xml reader when I had this issue.

Here's a link I found on asp.net

Mark Dickinson
Interesting. I have a test assembly (the one it's complaining about) and a separate assembly that it's supposed to be testing. Would the resource issue be in the test assembly? Or possibly something the test assembly is accessing in the main assembly isn't letting go of a resource. Hmm...
Chris
Don't want to send you off on a wild goose chase, but I would have thought that the offending code will be in the assembly you are testing rather than the test assembly. Look for things that use System.IO especially, they seem to be quite tardy.
Mark Dickinson
I hear ya. What's interesting is that I can load the NUnit project from scratch, and without running a single test (meaning it hasn't loaded my code yet...I think), it still blocks the IDE from compilation. I'll still check some things out though, thanks!
Chris
No worries, good luck.
Mark Dickinson
+11  A: 

Figured it out: the "Volume Shadow Copy" service was shut off for some reason. Turned it back on, and everything's back to normal.

Chris
Thanks for posting the fix!
Tim Stewart
Had the same problem, fix worked wonderfully!
John Rasch
Worked for me as well - but can anybody explain why? On the face of it, the Volume Shadow Copy service should have nothing to do with the VS Build process.
Samuel Jack
I wonder if the NUnit runner is using VSS to make a snapshot of the DLL.
Kurt
The strange thing is that the VSS service is supposed to start on-demand when a snapshot is requested.
Kurt
I had probably set it to "disabled" for whatever misguided reason, I'd figure.
Chris
+2  A: 

I had the same problem as mentioned in the Question. I solved it on my machine by the following:

  1. Within Visual Studio > Solution Explorer > select the dll that is causing the problem > right click > select properties. After this action the File properties of the dll should now be visible.
  2. Within the file properties view of the dll; set the Copy To Output Directory to Copy if newer.

If you have the Copy to Output Directory as Copy always you will get the compile error mentioned in the question. If you make the change mentioned above it should go away and your dll will still be copied.

Ryan Walker
Good catch, wish I could mark two as answered.
Chris