5

I have an integration test for a method in assembly A. Assembly A references assembly B via project reference. I run them under the Visual Studio 2010 debugger in a Resharper 6.1 unit testing scenario. The testing engine is Microsoft's native MSTest.

I get the infamous

The process cannot access the file ...\B.dll because it is being used by another process.

message. I have verified that no other process has a handle on that file (e.g. via Sysinternal's Process Explorer).

Running the test out of the debugger works fine. Any ideas why it happens under the debugger and what I can do to fix it?

Kit
  • 20,354
  • 4
  • 60
  • 103
  • Do you have any build events for project B? Is your test doing anything specific with B? – bryanbcook Nov 08 '12 at 02:48
  • Nothing special. The test project `A` worked fine before the `B` project reference, which is set to copy local btw. – Kit Nov 08 '12 at 15:15

3 Answers3

8

Building upon Sébastien's answer, I added a pre-build step to my test project to automatically kill any vstest.* executables still running. The following pre-build command worked for me:

taskkill /f /im vstest.*
exit 0

The exit 0 command is at the end to prevent build failure when there are no vstest.* executables running.

mrtumnus
  • 347
  • 4
  • 17
  • This was the quickest, most effective workaround for me. – Jon May 22 '15 at 14:23
  • Err. I don't understand pre-build events. I copypasted what you have here and I get errors: `The command "taskkill /f /im vstest.* exit 0" exited with code -1.` – Ian Grainger Oct 21 '16 at 15:32
  • You need to put `exit 0` on another line; *taskkill* is thinking you are using `exit` as an argument. – Kit Oct 21 '16 at 16:10
  • @Kit Yeah, this doesn't work for me :( My comment wasn't clear - with these two lines, if the process doesn't exist, I get an error building: `the process vstest.* was not found.` – Ian Grainger Oct 22 '16 at 06:12
  • @mrtumnus I used the answer here instead of exit 0 as that didn't work for me: http://superuser.com/a/433002/167358 - although it has to start a command window, it seems to work. – Ian Grainger Oct 22 '16 at 06:19
7

I have seen a similar situation, and found in the task manager that vtest.discoveryengine.exe and vtest.executionengine.exe were still alive. I killed both, which solved the problem.

Sébastien Barré
  • 96
  • 1
  • 3
1

Building upon @mrtumnus' answer and the answer here, I added a pre-build step to my test project to automatically kill any vstest.* executables:

START taskkill /f /im vstest.*

Using START instead of exit 0 so it doesn't give an error if the task isn't running. (It does open a command window, though, which is a bit annoying).

Community
  • 1
  • 1
Ian Grainger
  • 5,148
  • 3
  • 46
  • 72
  • with vs 2023 + resharper 2023 I experienced a similar problem that could be fixed with: (START /wait taskkill /f /im ReSharperTestRunner64.exe) & EXIT 0 – yBother Aug 09 '23 at 09:10