Предотвращать блокировку DLL файлов для обнаружения открытий vstest

У меня есть единичные тесты на С# для проекта VS2012, который вызывает VS2010 С++ DLL, используя DllImport pinvoke.

Как событие предварительной сборки для тестового проекта, я копирую последнюю версию DLL в бинарный проект для теста.

Это повторяется, если vstest.discoveryengine запущен. Похоже, что "механизм обнаружения" загружает тесты и удерживает блокировку в DLL.

Если я убью vstest engine, то я смогу построить и запустить тесты. в противном случае сборка завершится неудачей, а VS2012 предложит запустить предыдущую версию (с диалоговым окном модели, в котором отсутствует опция "Не показывать это сообщение снова" )

Есть ли что-то, что я могу сделать, чтобы заставить тестовый проект выгрузить DLL, когда он не выполнял тесты, или отключить исполняемый файл обнаружения фона?

Я взломал обходной путь, создав исполняемый файл под названием Kealakekua, который убивает vstest.discoveryengine.x86, vstest.executionengine.x86, и с этим в качестве первой части события предварительной сборки он может копировать файлы и создавать, но предпочел бы не бороться с visual studio для моего файла.

Ответы

Ответ 1

Недавно у меня была эта проблема, и проблема была вызвана моим собственным пользовательским кодом.

Во время обнаружения теста все тестовые классы создаются и в одном из наших конструкторов классов тестов были инициализированы довольно сложные бизнес-классы. Проблема в том, что во время инициализации был создан фоновый поток, который сделал следующее:

socket.Read(...)

Этот поток продолжал работать навсегда, ожидая появления некоторых данных сокетов и, как результат, заблокировал нашу сборку.

Итак, решение для меня состояло в том, чтобы убедиться, что этот код не будет вызван во время обнаружения теста.

Вы можете проверить, если вы затронуты этой проблемой, добавив Visual Studio к движку обнаружения теста, когда он заблокировал сборку. После нажатия паузы вы обычно увидите, что текущая строка выполнения находится где-то в вашем собственном коде пользователя (также проверьте окно Threads).

Ответ 2

У меня была аналогичная проблема, когда я создал проект "Тест", который на самом деле не имел никаких тестов. (Как разработчик библиотеки С++, я хотел убедиться, что некоторые заголовки могут быть скомпилированы с включенным CLR, поэтому я создал поддельный проект CLR, чтобы просто скомпилировать их с помощью CLR. Если он скомпилирован, он прошел.) Созданная DLL была открытые неограниченное время на vstest.discoveryengine.

Я исправил его, добавив в проект пропущенный тест. Я думаю, что vstest.discoveryengine будет храниться в dll, пока не найдет все тесты в dll, но если нет тестов, которые будут найдены, то он будет удерживаться на нем навсегда.

Тест, который я добавил (я думаю, что это тест по умолчанию). Обратите внимание на TEST_IGNORE(), чтобы убедиться, что он не выполнен:

#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
      }

   };
}

Я надеюсь, что это возможно в вашей ситуации.