verhindern vstest Entdeckungs-Engine locking DLLs

Question

Ich habe einige C# Unit-Tests für ein VS2012-Projekt, das eine VS2010 C++ DLL mit DllImport Pinvoke aufruft.

Als Pre-Build-Ereignis für das Testprojekt, kopiere ich die neueste Version der DLL in das Binärprojekt für den Test.

Dies schlägt wiederholt fehl, wenn vstest.discoveryengine ausgeführt wird. Es sieht so aus, als würde die 'discovery engine' die Tests laden und die DLL sperren.

Wenn ich Vstest-Discovery-Engine, dann kann ich die Tests erstellen und ausführen. ansonsten die Erstellung fehl, und VS2012 bietet eine frühere Version (mit einem Modell Dialog, der keine ‚diese Meldung nicht mehr anzeigen‘ Option hat) läuft

Gibt es etwas, was ich tun kann, entweder um den Test zu zwingen Projekt, um die DLL zu entladen, wenn die Tests nicht ausgeführt werden, oder um die ausführbare Hintergrundermittlung zu deaktivieren?

Ich habe eine Workaround gehackt, indem Sie eine ausführbare Datei namens Kealakekua erstellt, die vstest.discoveryengine.x86, vstest.executionengine.x86, und damit als erster Teil des Pre-Build-Ereignisses kopiert die Dateien und Build , würde aber lieber nicht visuelles Studio für meine Datei kämpfen.

Answer 1

Ich hatte ein ähnliches Problem, wo ich ein "Test" -Projekt erstellte, das tatsächlich keine Tests darin hatte. (Als C++ - Bibliotheksentwickler wollte ich sicherstellen, dass bestimmte Header mit CLR kompiliert werden konnten, also habe ich ein falsches CLR-Projekt erstellt, um sie einfach mit CLR zu kompilieren. Wenn es kompiliert wurde, wurde es übergeben.) Die erstellte DLL wurde offen gehalten von der vstest.discoveryengine.

Ich habe es durch Hinzufügen eines Ignorierten Tests zum Projekt behoben. Ich denke, dass vstest.discoveryengine an der DLL festhalten wird, bis es alle Tests in der DLL findet, aber wenn keine Tests gefunden werden, dann wird es für immer festhalten.

Der Test Ich habe (ich denke, es ist der Standard-Test) Beachten Sie die TEST_IGNORE() sicherzustellen, dass es nicht ausgeführt wird:

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

    }; 
} 

Ich hoffe, dies in Ihrer Situation möglich ist.

Answer 2

Ich hatte vor kurzem auch dieses Problem und das Problem wurde von meinem eigenen Benutzercode verursacht.

Während der Test-Erkennung werden alle Testklassen instanziiert, und in einem unserer Testklassenkonstruktoren wurde eine recht komplexe Geschäftsklasse initialisiert. Das Problem ist, dass bei der Initialisierung der es sich um ein Hintergrund-Thread erstellt wurde, das die folgende tat:

socket.Read(...) 

Dieser Faden gehalten immer warten einige Socket Daten zu gelangen und als Ergebnis unserer Versammlung gesperrt.

Also war die Lösung für mich sicherzustellen, dass dieser Code während der Testentdeckung nicht aufgerufen wird.

Wenn Sie von diesem Problem betroffen sind, können Sie überprüfen, ob Visual Studio der Test Discovery Engine beigefügt wird, wenn eine Assembly gesperrt wurde. Nach dem Drücken von Pause wird man normalerweise sehen, dass die aktuelle Ausführungszeile irgendwo in Ihrem eigenen Benutzercode ist (überprüfen Sie auch das Threads-Fenster).