VS2012 Test explorer blocca nativo .dll, rendendo impossibile la ricostruzione

Question

Sto utilizzando Visual Studio 2012 per una soluzione con un C# e un .dll C++/CLI, con la dll C++/CLI che fa riferimento a dll nativi come boost. Il codice C++ è compilato come x64.

Quando apro VS, posso pulire e creare il mio progetto.

Utilizzando test explorer, posso eseguire i miei test.

Non appena ho usato test explorer per eseguire i test una volta, non riesco a ricostruire il progetto. Sembra che VS2012 test Explorer mantiene un blocco sul mio C++/CLI-dll, e lì ho il seguente errore:

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

Come conseguenza di questo, ogni volta che ho eseguito i test con il test Explorer, ho bisogno per riavviare VS2012 prima di poter continuare a sviluppare. Ovviamente questo non è un processo di sviluppo sostenibile.

Test e ricostruzione funziona senza problemi con C# -due DLL - per quanto posso dire il problema si verifica solo con DLL che utilizzano il codice x64 nativo.

Dopo alcuni test, ho scoperto che il cattivo qui è vstest.executionengine.exe. Usando handle (da SysInternals), vedo che vstest.executionengine.exe contiene blocchi per .dll e .pdb del cli-dll. Non contiene alcun blocco per le DLL solo gestite.

Come posso ottenere Visual Studio Test Explorer per rilasciare i blocchi sulle DLL C++/Cli dopo il completamento delle esecuzioni di test?

Answer 1

Dopo un po 'di ricerche, ho trovato this post on connect.microsoft.com. L'ultimo suggerimento in soluzioni alternative risolve il problema, anche se è un brutto scherzo.

posso ricostruire se aggiungo il seguente come pre-costruire eventi alla mia C++/CLI dll:

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

Questo ucciderà il processo vstest.executionengine.exe, liberando in tal modo la serratura della mia dll file.

Answer 2

ho anche combattuto questo problema e inizialmente utilizzato la soluzione alternativa "taskkill", ma ho appena inciampato su un'opzione nelle impostazioni di VS2013, che sembra risolvere più elegantemente questo problema:

Rimuovere il segno di spunta sulla

Tenere prova motore di esecuzione in funzione tra test viene eseguito opzione

trovato alla

Strumenti/Opzioni/Web Performance Tools test

Answer 3

Ho anche incontrato questo problema durante il test che coinvolge DLL native. La soluzione alternativa (soluzione?) Che ho trovato è stata quella di aggiungere un DeploymentItemAttribute ai test - non sono sicuro se questo è generalmente vero, ma sicuramente ha funzionato per me. È un po 'un dolore se ce ne sono molti (ne avevo 6 nel mio caso), ma una volta fatto è stato facile copiare e incollare gli altri test.

Quindi la mia classe di unit test simile a questa:

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

Answer 4

avevo scritto un'utility C# per essere in grado di caricare e scaricare le librerie native in here ho usato nel progetto di test come di seguito. Dal momento che scarica dll in Dispose, non ho errori di compilazione.

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

In Visual Studio 2013, tale problema può facilmente essere fissato deselezionando l'opzione "Mantieni prova Esecuzione motore in funzione" in "Test -> Impostazioni di prova" nel menu.

ho trovato la risposta in un altro post: vstest.executionengine.x86.exe not closing

Answer 6

Aggiungendo alcune cose alla risposta di @frodesto, (in caso di VS2013), "Test> Prova Impostazioni> Tenere prova Executin Motore in moto" la configurazione viene memorizzata nella configurazione utente (file SUO). Questo può essere un po 'brutto in caso di questo errore si verifica nell'agente di creazione TFS, perché utilizza un utente predefinito del servizio.

Per risolvere questo caso, prima uccidere il file esistente vstest.executionengine.exe, modificare l'utente utilizzato dall'agente di creazione TFS da eseguire con l'utente al quale si è connessi. Aprire la soluzione memorizzata nello spazio di lavoro dell'agente di TFS Build e deselezionare l'opzione. Successivamente, l'agente TFS Build leggerà l'opzione "mantieni il motore di esecuzione del test" perché il file SUO è per lo stesso utente.