VS2012 Eksplorator testów blokuje natywny plik .dll, powodując niepowodzenie odbudowy.

Question

Używam Visual Studio 2012 do rozwiązania z C# i C++/CLI .dll, z dll C++/CLI odwołującego się do rodzimych .dll takich jak boost. Kod C++ jest skompilowany jako x64.

Po otwarciu VS mogę wyczyścić i zbudować swój projekt.

Korzystając z eksploratora testów, mogę uruchomić moje testy.

Gdy tylko użyję testowego eksploratora do przeprowadzenia testów raz, nie mogę odbudować projektu. Wydaje się, że VS2012 testowania Explorer utrzymuje blokadę na moim C++/CLI-dll, a tam pojawia się następujący błąd:

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

W wyniku tego, kiedy mam uruchomić testy testem Explorer, muszę aby ponownie uruchomić VS2012, zanim będę mógł dalej się rozwijać. Oczywiście nie jest to proces zrównoważonego rozwoju.

Testowanie i przebudowywanie działa bez problemu z C# -only dll - o tyle, na ile mogę powiedzieć, że problem występuje tylko z bibliotekami DLL, które korzystają z natywnego kodu x64.

Po kilku kolejnych testach odkryłem, że złoczyńcą jest tutaj vstest.executionengine.exe. Używając uchwyt (z SysInternals), widzę, że vstest.executionengine.exe przechowuje blokady dla .dll i .pdb z cli-dll. Nie ma żadnych blokad dla bibliotek DLL tylko do zarządzania.

Jak mogę uruchomić Eksploratora testów Visual Studio, aby zwolnić blokady w bibliotekach C++/Cli po zakończeniu testów?

Answer 1

Po dalszych poszukiwaniach znalazłem this post on connect.microsoft.com. Ostatnia wskazówka w rozwiązaniu problemu rozwiązuje problem, chociaż jest to brzydki hack.

mogę odbudować jeśli dodać następujące jako wstępnie zbudować zdarzenia do mojego C++/CLI DLL:

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

To zabije proces vstest.executionengine.exe, uwalniając w ten sposób blokadę na mojej .dll plik.

Answer 2

Mam również zwalczaniu tego problemu i początkowo używane „taskkill” obejście, ale ja po prostu potknął się opcja w ustawieniach VS2013, który wydaje się bardziej elegancko rozwiązać ten problem:

usuń zaznaczenie znak na

Przechowywać testowy silnik na wykonanie testu przebiega między

opcję znaleźć na

Narzędzia/Opcje/Performance WWW Narzędzia testowe

Answer 3

Ja również napotkał ten problem podczas testowania w odniesieniu do natywnych bibliotek DLL. Obejście (rozwiązanie?), Które znalazłem, to dodanie DeploymentItemAttribute do testów - nie jestem pewien, czy to generalnie prawda, ale z pewnością zadziałało. To trochę problem, jeśli jest ich dużo (w moim przypadku było ich 6), ale po ich wykonaniu łatwo było skopiować i wkleić do innych testów.

Więc moja klasa testów jednostkowych wygląda mniej więcej tak:

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

Answer 4

I napisał # użyteczność C, aby być w stanie załadować i rozładować bibliotek natywnych w here Używałem go w ramach projektu badawczego, jak poniżej. Ponieważ zwalnia dll w Dispose, nie dostaję błędów kompilacji.

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(); 
     //... 
    } 
} 

Answer 5

W Visual Studio 2013 problem ten może być łatwo ustalony przez odznaczając opcję „Keep badania jezdnego Execution Engine” w ramach „testu -> Ustawienia testowe” w menu.

znalazłem odpowiedź w innym poście: vstest.executionengine.x86.exe not closing

Answer 6

dodając kilka rzeczy do odpowiedzią @frodesto, (w przypadku VS2013), „Test> Ustawienia testowania> Zachowaj test poleceni Silnik działa” konfiguracja jest przechowywana w konfiguracji użytkownika (plik SUO). Może to być trochę nieprzyjemne w przypadku, gdy ten błąd wystąpi w agencie budowania TFS, ponieważ używa on domyślnego użytkownika usługi.

Aby naprawić ten przypadek, najpierw należy zabić istniejący plik vstest.executionengine.exe, zmodyfikować użytkownika używanego przez agenta TFS Build do wykonania z użytkownikiem, na którym się zalogowano. Otwórz rozwiązanie przechowywane w przestrzeni roboczej agenta Build TFS i odznacz opcję. Następnie agent TFS Build odczyta opcję "keep testing execution engine", ponieważ plik SUO jest dla tego samego użytkownika.