VS2012 Test explorer блокирует native.dll, что приводит к сбоям в восстановлении

Я использую Visual Studio 2012 для решения с С# и С++/CLI.dll, с dll С++/CLI, ссылающимися на родные DLL файлы, такие как boost. Код С++ скомпилирован как x64.

Когда я открываю VS, я могу очистить и построить свой проект.

Используя тестовый проводник, я могу запустить свои тесты.

Как только я использовал тестовый проводник для запуска тестов один раз, я не могу перестроить проект. Кажется, что VS2012 Test Explorer хранит блокировку моей С++/CLI-dll, и там я получаю следующую ошибку:

LNK1104: cannot open file 'C:\Dev\LockExample\bin\Debug\cli.dll'

В результате этого, всякий раз, когда я запускал тесты с помощью Test Explorer, мне нужно перезапустить VS2012, прежде чем я смогу продолжить разработку. Очевидно, что это не процесс устойчивого развития.

Тестирование и восстановление работают без проблем с С# - только DLL - насколько я могу сказать, проблема возникает только с DLL, которые используют собственный x64-код.

После еще нескольких тестов я обнаружил, что злодеем здесь является vstest.executionengine.exe. Используя handle (из SysInternals), я вижу, что vstest.executionengine.exe содержит блокировки для .dll и .pdb cli-dll. Он не содержит блокировок для управляемых DLL.

Как я могу заставить Visual Studio Test Explorer освободить блокировки на DLL С++/Cli после завершения тестовых запусков?

Ответ 1

После еще нескольких поисков я нашел этот пост на сайте connect.microsoft.com. Последний намек на обходные пути действительно решает проблему, хотя это уродливый взлом.

Я могу перестроить, если я добавлю следующие события pre-build в свою DLL С++/CLI:

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

Это приведет к уничтожению процесса vstest.executionengine.exe, тем самым освободив блокировку моего файла .dll.

Ответ 2

В Visual Studio 2013 эту проблему можно легко устранить, сняв флажок в опции "Keep Test Execution Engine Running" в разделе "Test → Test Settings" в меню.

Я нашел ответ в другом посте: vstest.executionengine.x86.exe не закрывается

Ответ 3

Я также столкнулся с этой проблемой при тестировании с использованием родных DLL. Обходной путь (решение?), Который я нашел, заключался в том, чтобы добавить тесты DeploymentItemAttribute к испытаниям - не уверен, что это вообще так, но это, безусловно, сработало для меня. Это немного больно, если их много (у меня было 6 в моем случае), но после этого было легко скопировать и вставить другие тесты.

Итак, мой класс unit test выглядит примерно так:

[TestClass]
public class TestMyClass
{
    [TestMethod]
    [DeploymentItem("firstnative.dll")]
    [DeploymentItem("secondnative.dll")]
    public void TestMyMethod()
    {
        //Code which (indirectly) uses the above native dlls.
    }
}

Ответ 4

Я также борюсь с этой проблемой и изначально использовал обходной путь "taskkill", но я просто наткнулся на опцию в настройках VS2013, которая, кажется, более элегантно решает эту проблему:

Снимите отметку на

Держите механизм выполнения тестов, запущенный между тестовыми запусками

найденный в

Инструменты/Параметры/Инструменты проверки производительности Web

Ответ 5

Я написал утилиту С#, чтобы иметь возможность загружать и выгружать собственные библиотеки в здесь Я использовал его в тестовом проекте, как показано ниже. Поскольку он выгружает DLL в Dispose, я не получаю ошибки сборки.

public interface INativeCrypto : INativeImport
{
    [ImportFunction("mynative.dll"]
    int NativeMethod();
}


[TestClass]
public class UnitTest1
{
    public void TestMethod1()
    {
        INativeCrypto impl = NativeImport.Create<INativeCrypto>("");

        // Use methods in impl
        int i = impl.NativeMethod();
        //...
    }
}

Ответ 6

Добавление некоторого материала в ответ @frodesto (в случае VS2013), "Test > Test Setting > Keep Test Executin Engine running" конфигурация сохраняется в пользовательской конфигурации (SUO файл). Это может быть немного неприятно в случае возникновения этой ошибки в агенте Build TFS, поскольку он использует пользователя по умолчанию для службы.

Чтобы исправить этот случай, сначала удалите существующий файл vstest.executionengine.exe, измените пользователя, используемого агентом Build TFS, для выполнения с пользователем, с которым вы вошли в систему. Откройте решение, хранящееся в рабочей области агента TFS Build, и отмените выбор опции. После этого агент сборки TFS будет читать параметр "сохранить механизм выполнения теста", поскольку файл SUO предназначен для одного и того же пользователя.