27

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.

Chris
  • 4,030
  • 4
  • 47
  • 76

6 Answers6

37

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
  • 4,030
  • 4
  • 47
  • 76
  • 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 Jun 21 '10 at 16:52
  • I wonder if the NUnit runner is using VSS to make a snapshot of the DLL. – kgriffs Jul 21 '10 at 18:44
  • The strange thing is that the VSS service is supposed to start on-demand when a snapshot is requested. – kgriffs Jul 21 '10 at 19:26
  • I had probably set it to "disabled" for whatever misguided reason, I'd figure. – Chris Jul 22 '10 at 15:40
  • Mine was on Manual; so I set it to Automatic. – kamranicus Feb 12 '11 at 04:52
  • where is this service located? – Louis Rhys Aug 28 '12 at 03:14
  • 1
    @LouisRhys: Windows Services. Start->Run->services.msc, or via whatever start menu hierarchy. – Chris Aug 28 '12 at 12:56
  • @Chris does this belong to the VS or to NUnit? I can't find it in my services, any idea? – Louis Rhys Aug 28 '12 at 13:27
  • How on earth VSC has something to do with the VS build process is incomprehensible. These things are sent to try us >;-) – smirkingman Sep 12 '12 at 12:46
  • 1
    The Volume Shadow Copy service is part of Windows. It seems to me that the NUnit authors used good judgment in using a service provided by the OS rather than rolling their own. Perhaps the main hazard here is VSC getting turned off when developers try to clean out bloatware. – Technophile Mar 18 '14 at 19:10
  • @Technophile It's been almost five years since I ran into the problem and its cause, but I'm almost positive I brought the issue on myself because I read some "speed your dev machine up!" blog nonsense that recommended turning it off. – Chris Apr 03 '14 at 12:32
  • 1
    It worked. However I still don't know what was it caused by? I suspect that a race condition still exists in code but the shadow copy service finds a way not to hit it, so the answer is just workaround rather than proper fix. Just my guess based on my own code. – matcheek Oct 13 '15 at 10:49
10

I just wanted to add that moving the Nunit project file to the solution location solved my issue. I did not have to change any shadow copying setting in nunit or to enable shadow copying service.

See Stack Overflow - nunit locking dll

Community
  • 1
  • 1
Valamas
  • 24,169
  • 25
  • 107
  • 177
  • 2
    BTW it's not necessary to actually have them in the same directory. Updating the `Project Base` in NUnit GUI project settings to point to the solution directory does the trick too. No need for Volume Shadow Copy – Kos Jan 22 '12 at 14:40
  • +1 this solution worked for me when the accepted answer didn't. Thanks for the addition. – Liath Nov 19 '14 at 11:19
3

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
  • 841
  • 8
  • 12
  • 1
    Hmm, in my project the bin/obj directories are not included in the project itself, so the "Copy to output Directory" option is not actually available. VSS doesn't seem to help either, are there other options? – Shagglez Mar 31 '11 at 09:52
2

I had the same problem :

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.

The cause in my case seemed to be that I used the same namespace in two assemblies:

  1. MyNUnitTestLibrary 'wrapped' the test classes in "namespace bank {...}"
  2. 'NUnit Quick Start' also had everything inside "namespace bank {...}"

Changing one of the namespace names fixed the problem. I have made several changes to both assemblies and re-compiled without the error

Note that both assemblies contain tests,as I a play with NUnit.

StKiller
  • 7,631
  • 10
  • 43
  • 56
Grog
  • 21
  • 1
1

I had this problem, and after a lot of reading around and experimentation, I realized the culprit was not actually anything in NUnit or my code. It was another library I was using, FakeItEasy, a mock object framework, which was failing to properly release all it's resources.

If you're using FakeItEasy with NUnit and encounter this problem, consider switching to another mock object framework. If you're not using FakeItEasy, or if removing it from your project doesn't fix this, take an inventory of all the 3rd party libraries you are utilizing from the test code, and consider if any of them might be doing something similar.

Alternately, pester the creator of NUnit to explicitly release any resources held by any of the test assemblies it loads, or if you're much more proactive than I, take advantage of the fact that it's an open source project and contribute a solution that does this.

Michael Powell
  • 853
  • 2
  • 9
  • 12
1

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
  • 6,573
  • 4
  • 29
  • 41
  • 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 Jun 01 '09 at 15:38
  • 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 Jun 01 '09 at 15:45
  • 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 Jun 01 '09 at 15:48