prevent vstest discovery engine locking DLLs

Question

I have some C# unit tests for a VS2012 project which calls a VS2010 c++ DLL using DllImport pinvoke.

As a pre-build event for the test project, I copy the latest versio

Answer 1

I had a similar problem where I created a "Test" project that didn't actually have any tests in it. (As a C++ Library developer I wanted to make sure that certain headers were able to be compiled with CLR enabled, so I made a fake CLR project to just compile them with CLR. If it compiled, it passed.) The DLL created was being held open indefinitely by the vstest.discoveryengine.

I fixed it by adding an Ignored test to the project. I think vstest.discoveryengine will hold on to the dll until it finds all the tests in the dll, but if there are no tests to be found, then it will hold onto it forever.

The test I added (I think it is the default test) Note the TEST_IGNORE() to make sure it isn't executed:

#include <CppUnitTest.h>

namespace CLRTests
{
   TEST_CLASS(CLRTestsClass)
   {
   public:

      BEGIN_TEST_METHOD_ATTRIBUTE(CLRTest1)
         TEST_OWNER(L"")
         TEST_DESCRIPTION(L"")
         TEST_PRIORITY(1)
         TEST_IGNORE()
         END_TEST_METHOD_ATTRIBUTE()
         TEST_METHOD(CLRTest1)
      {
         // TODO: Your test code here
      }

   };
}

I hope this is possible in your situation.

Answer 2

I recently also had this issue and the problem was caused by my own user code.

During test discovery all the test classes are instantiated and in one of our test class constructors, a quite complex business classes was initialized. The problem is that during initialization of it a background thread was created, that did the following:

socket.Read(...)

This thread kept running forever waiting for some socket data to arrive and as a result locked our assembly.

So the solution for me was to make sure this code won't get called during test discovery.

You can check, if you are affected by this issue, by attaching Visual Studio to the test discovery engine when it has locked some assembly. After pressing pause you normally will see, that the current executing line is somewhere in your own user code (also check the Threads window).