CODEWITHSUNDEEP
visual-studio-2012
Pete Kirkham
Pete Kirkham

Reputation: 49331

prevent vstest discovery engine locking DLLs

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 version of the DLL to the binary project for the test.

This repeatedly fails if vstest.discoveryengine is running. It appears that the 'discovery engine' is loading the tests and holding the lock on the DLL.

If I kill vstest discovery engine, then I can build and run the tests. otherwise the build fails, and VS2012 offers to run a previous version ( with a model dialog which doesn't have a 'don't show this message again' option)

Is there something I can do to either force the test project to unload the DLL when not actually running the tests, or to disable the background discovery executable?

I've hacked a workaround by creating an executable called Kealakekua which kills vstest.discoveryengine.x86, vstest.executionengine.x86, and with that as the first part of the pre-build event it can copy the files and build, but would prefer not to be fighting visual studio for my file.

Upvotes: 21

Views: 5415

Answers (2)

paiden
paiden

Reputation: 887

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).

Upvotes: 2

user2533647
user2533647

Reputation: 11

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.

Upvotes: 1

Related Questions