nunit-core team mailing list archive

[Michael Powell <619679@xxxxxxxxxxxxxxxxxx>]

I was encountering this same problem, and after a good deal of
investigation I did eventually figure it out. At least in my case, it
wasn't entirely NUnit's fault. I was also using FakeItEasy, the mock
object framework, and I found that if I commented out all the calls to
FakeItEasy, the NUnit process successfully released all the extra
references to my libraries. It appears FakeItEasy was holding on to
resources it shouldn't have. I switched over to Moq, and stopped having
this problem.

That said, I think this could still be handled better by NUnit, by
explicitly releasing any resources held by any of the assemblies it's
loaded after the tests have finished running. While it's bad practice
for any code to open resources and fail to release them, you can't count
on all the code being run through NUnit following best practices, and
handling this case would avoid a lot of cryptic errors like this.
Ideally, any time NUnit has to release those resources, it would show
some kind of warning about it, so the developer knows there is a problem
they should be fixing.

I'm using:
NUnit 2.5.10
FakeItEasy 1.7.4166.27
Visual C# 2008 Express
Windows 7 Home x64
Compiling to .NET 3.5

-- 
You received this bug notification because you are a member of NUnit
Developers, which is subscribed to NUnit V2.
https://bugs.launchpad.net/bugs/619679

Title:
  NUnit 2.5.7.10213 GUI TestRunner Locks Test Assembly

Status in NUnit V2 Test Framework:
  Fix Released

Bug description:
  After opening and running an NUnit project in the GUI test runner I am
  unable to build my solution in Visual Studio. The build fails with the
  following error.

  Unable to copy file "C:\Projects\Foo\Foo.Bar\bin\Debug\Foo.Bar.dll" to
  "bin\Debug\Foo.Bar.dll". The process cannot access the file
  'bin\Debug\Foo.Bar.dll' because it is being used by another process.

  Foo.Bar.dll is the assembly under test, my tests are in a separate
  assembly, Foo.Bar.Tests.dll which has a referrence to the Foo.Bar
  project.

  I have to close the NUnut project, rebuild then reopen the project. 
  This was not an issue in NUnit 2.5.3 (2.5.3.9345). The GUI would not lock an files, rebuilding the solution triggered a reload of the assemblies.