[nunit-discuss] Unable to copy file error

[~-=Mike=-~]

When I recompile I am getting the following error:

Unable to copy file "obj\Debug\<myproject>.dll" to "bin\Debug
\<myproject>.dll". The process cannot access the file 'bin\Debug
\Blog.Specs.dll' because it is being used by another process.
Blog.Specs

I'm using VS2010 and SpecFlow for my unit testing. I don't think
either of these are a factor to this bug.

In the Settings | Assembly Reload: I have all three options selected.

When I select the root level in the Tests tree within the NUnit GUI
and recompile there is no compiler error and all of the tests are run
as expected.

However, when I select a specific test within the Tests tree and then
recompile I get the error. When switch back to the root again
recompile works fine.

It seems there is a file lock when a specific test is selected.

--
You received this message because you are subscribed to the Google Groups "NUnit-Discuss" group.
To post to this group, send email to nunit-...@googlegroups.com.
To unsubscribe from this group, send email to nunit-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nunit-discuss?hl=en.

[Charlie Poole]

Hi Mike,

I suggest you pick one of the two reload options. What seems to be
happening is that the first reload has not yet released the file when the
second reload fires off. If this turns out to be true, please file a bug.

Charlie

[Charlie Poole]

If I remember correctly (that post is almost three years old) the problem was with selecting all three options in Settings | Assembly Reload.

This leads to the sequence:

1. The user recompiles the test assembly

2. "Reload when test assembly changes" triggers a reload of the assembly by NUnit

3. "Re-run last tests run" causes the tests to be executed

4. "Reload before each test run" causes *another* reload before the execution begins

Usually, this doesn't cause a conflict, but some times it does - at least according to reports we've received.

Making changes to how and where the test is loaded could easily break this cycle. In particular, if your tests are in a separate process, many causes of conflict are eliminated.

There's probably a bug in here somewhere. In the above example, the second reload is completely unnecessary but is performed because the code doesn't "know" that the rerun has already been caused by a reload. If someone wants to take a shot at formulating how this could work better and file a bug on it, I'd be glad to consider it.

Charlie

On Thu, Apr 4, 2013 at 6:44 AM, Robert Snyder <immerau...@yahoo.com> wrote:

I had same problem, and it was even going a step further in that in Visual Studio it would say that it could not find the assembly. I found a fix though. For me it had nothing to do with the reload it had to do with the isolation.

I had "Use a single AppDomain for all tests" selected and had your problem. Now it is set to "Use a separate AppDomain per Assembly" and in the Default Process Model I have selected "Run tests in a single separate process" Now I can build over and over again.

Hope this helps.

To unsubscribe from this group and stop receiving emails from it, send an email to nunit-discus...@googlegroups.com.

To post to this group, send email to nunit-...@googlegroups.com.

Visit this group at http://groups.google.com/group/nunit-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.