4

I wrote a custom class library for NUnit unit tests. It created a dll file containing my .NET IL code in the {project root}\bin\Debug\ folder. Running NUnit unit tests in this class library works fine, but if I try to compile my class library again, I get this error. NUnit isn't releasing the lock. What is causing this? How can I prevent this from occurring?

Visual Studio error when compiling after NUnit runs for first time:

Error {error #} {class library project name} Unable to copy file {class library project root folder} + "\bin\Debug\Tests.dll" to "bin\Debug\Tests.dll". The process cannot access the file 'bin\Debug\Tests.dll' because it is being used by another process.

So the only way I can change the code is to close NUnit and re-open NUnit. I'm using NUnit 2.6. It's very annoying.

JustBeingHelpful
  • 18,332
  • 38
  • 160
  • 245

2 Answers2

1

The only way I have found to deal with that is to restart NUnit. This releases the lock, however the next time that you run the tests you may have the same problem.

However, you can take a look at this info that might help:

It could be a reload setting, per this google groups thread

See the Assembly Isolation section

OR finally:

It could be the location of your code bases?

Community
  • 1
  • 1
Justin Pihony
  • 66,056
  • 18
  • 147
  • 180
  • When I first started using NUnit (first few months), it didn't do this. It started locking the file last week. I was more curious on how to prevent this, not how to fix it. If you find a solution, let me know. For now, I'm just killing the lock forcefully with a Windows tool. – JustBeingHelpful Apr 09 '12 at 17:01
  • 1
    @MacGyver I updated my answer. Playing with assembly reloads might help here? – Justin Pihony Apr 09 '12 at 17:05
  • thanks for helping Justin.. I'll give you a few points for sharing this knowledge.. up-voted your comment. If you find a workflow that's different from mine that also causes this, it would be good to know. – JustBeingHelpful Apr 09 '12 at 17:28
1

I found the cause. Perhaps an NUnit developer can fix this. For now, I have the workaround described below.

If you DO NOT have your *.nunit, *.VisualState.xml (auto-generated NUnit file) and *.config (NUnit configuration file that is referenced from the Visual Studio class library using System.Configuration not NUnit's config file setting) inside of the class library root folder, this will occur. (And my *.config file is named the same as my *.nunit file, so I have Tests.config and Test.nunit, both sharing the name "Tests")

So for example when I get this error, I have the following setup:

My class library is called "Tests.csproj". And suppose Tests.csproj is in "C:\Source\Tests\". That would make "C:\Source\Tests\" the root of my project folder. My dll is in "C:\Source\Tests\bin\Debug\Tests.dll". And the NUnit files described above are in "C:\Source\Tests\NUnit\".

When I move the NUnit files to "C:\Source\Tests\" (class library project root folder), I don't get this issue when I try compiling Visual Studio class library project. This folder structure causing this must confuse the NUnit program.

The reason I have a separate folder was to keep all of the NUnit files separated. After fixing this, I prefixed all of the *.nunit, *.xml and *.config files with "nunit_" so they're all grouped together.

JustBeingHelpful
  • 18,332
  • 38
  • 160
  • 245