vstest.executionengine.x86.exe not closing

2019-01-31 02:52发布

I've encountered an error when running unit tests. If I Debug the unit tests vstest.executionengine.x86.exe runs, then closes when the tests pass.

If I just run the tests (Even if the test is as simple as just creating a new list, with no asserts) vstest.executionengine.x86.exe doesn't close and stays running in task manager.

This is causing an issue for me when it comes to writing more complicated tests that include removing files / cleaning up sqllite databases.

Any help would be appreciated.

EDIT :

Steps to reproduce :

  • Create New Unit Test Project
  • Debug Unit Tests - vstest.executionengine.x86 opens and closes, test passes.
  • Run Unit Tests - vstest.executionengine.x86 opens and stays open

5条回答
劫难
2楼-- · 2019-01-31 03:03

This is by design.

The vstest.executionengine.exe is restarted only when we detect a change in the configuration between two consecutive test runs. This helps ensure we aren't taking a perf hit on process restarts unnecessarily.

Product Update With VS2013 we have a new menu item under Test -> Test Settings called "Keep Test Execution Engine Running". You can uncheck this to opt out of the default behavior.

查看更多
叼着烟拽天下
3楼-- · 2019-01-31 03:20

For what its worth, I ran into this same situation and it turned out that I had a test that did not properly clean up all of its resources. In my specific case there was a background thread with a network connection open that did not get closed before the test exited. Not sure why exiting the test did not close this for me, but when i fixed my code to properly dispose of all the resources I opened, everything worked as expected. I did not have to add any hacks to kill the vstest.executionengine.exe, nor did I have to opt out of Test -> Test Settings -> Keep Test Execution Engine Running

查看更多
男人必须洒脱
4楼-- · 2019-01-31 03:22

I had this issue when running test using Resharper's test runner which doesn't seem to respect the Test-->Test Settings-->Keep Test Execution Engine Running setting. In my case it was causing the build to fail with the following error:

warning MSB3026: Could not copy "...\SQLite.Interop.dll" to "bin\Debug\x86\SQLite.Interop.dll". Beginning retry 10 in 1000ms. The process cannot access the file 'bin\Debug\x86\SQLite.Interop.dll' because it is being used by another process.

Adding a pre-build event to the test project as @HappyCat suggested worked for me. I also needed to wrap it in an if statement to prevent it from running on the build server and interfering with other jobs.

if $(ConfigurationName) == Debug (
    echo "attempting to kill vstest to prevent access denied on sqlite.interop.dll"
    taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"
)
查看更多
Anthone
5楼-- · 2019-01-31 03:28

I know this is old but I thought I'd throw in something I just discovered.

A test I was running had some objects in it that implemented IDisposable, so the code analysis told me so should my test class. It took a while to realize it, but when this.Dispose(); was getting called on the implementation of that interface when I put it on my test class, it was actually throwing a StackOverflow exception. So I just yanked the interface and let CA continue to whine.

I did not need to toggle 'Keep Test Execution Engine Running'.

查看更多
兄弟一词,经得起流年.
6楼-- · 2019-01-31 03:29

I worked around this by using the following as a pre-build event on the affected test projects:

for 64-bit:

taskkill /F /IM vstest.executionengine.exe /FI "MEMUSAGE gt 1"

or for 32-bit:

taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"

This silently kills the execution engine before building the test project. The /FI "MEMUSAGE gt 1" stops the command (and therefore the build) from failing if the execution engine isn't running.

查看更多
登录 后发表回答