NUnit: “The process cannot access the file … because it is being used by another process.”

Question

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, an

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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

Answer 5

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.

Answer 6

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