SQLite.Interop.dll bloccato dopo che eseguono Visual Studio 2012 Unità quadro di prova test

Question

• Visual Studio 2012
• SQLite 1.0.82.0 (da NuGet)

Sto cercando di utilizzare il "Run All" comando nel "test Explorer" il seguente errore si verifica dopo aver eseguito il test una volta ... dopo che non costruirà più, fino a quando si riavvia visual Studio

Ecco l'errore di generazione

il processo non può accedere al file 'SQLite.Interop.dll' perché è utilizzato da un altro processo

ecco il codice

using System.Data.SQLite; 
using Microsoft.VisualStudio.TestTools.UnitTesting; 

namespace Test.Sqlite 
{ 
    [TestClass] 
    public class Test_Sqlite_Locking 
    { 
     [TestMethod] 
     public void can_create_table() 
     { 
      using(var fact = new SQLiteFactory())    
      using (var conn = fact.CreateConnection()) 
      { 
       conn.ConnectionString = "Data Source=:memory:;Version=3;New=True;"; 
       conn.Open(); 
       //conn.Close();     
      } 

      //SQLiteConnection.ClearAllPools(); 
      //GC.Collect(); 
     } 
    } 
} 

Ho provato, chiusura della connessione, chiamando ClearAllPools, GC.Collect e creando SQLiteConnection direttamente (anziché Factory) ... ancora lo stesso problema

Questo funziona se DEBUGATE TUTTI I TEST ... ma è quando si eseguono i test che si s sembra bloccarlo fino

Answer 1

Assicurarsi inoltre che il database viene installato nella cartella corretta
SQLite Connection Strings

adattatore

dati che si consiglia di provare come bene usando SQL Lite Using SQLitew with .NET

SQLiteConnectionStringBuilder builder = new SQLiteConnectionStringBuilder(); 
builder.FailIfMissing = true; 
builder.DataSource = "Insert the fully qualified path to your sqlite db"; 
SQLiteConnection connection = new SQLiteConnection(builder.ConnectionString); 
try 
{ 
    connection.Open(); 
} 
catch(SqlException exp) 
{ 
    // Log what you need from here. 
    throw new InvalidOperationException("Whatever exception you want to throw", exp); 
} 

Leggi questo articolo per vedere se aiuta a correggere il tuo problema System.Data.SQLite.View Ticket

Answer 2

Prova questo:

• In VS.NET, fare clic su Strumenti \ Opzioni
• Quando viene visualizzata la finestra di dialogo, cliccare su "Strumenti di prova"
• Cliccare su "Test Execution"
• deselezionare la casella " mantenere motore di esecuzione L'esecuzione del test tra i test"
• Fare clic su OK e riavviare VS.NET

Si dovrebbe essere test basati corsa SQLite in grado ora senza dover riavviare.

Answer 3

non riuscivo a trovare questa opzione in VS2012 (almeno non per i test unitari), quindi mi si avvicinò con un'altra soluzione:

Il problema si sta affrontando deriva dal fatto che il corridore unit test rimane caricato in modo che le corse ripetute siano più veloci. Dal momento che lo SQLite.Interop.dll probabilmente non cambierà troppo spesso, ho modificato l'opzione CopyToOutputDirectory a PreserveNewest anziché il valore predefinito Always.

È possibile eseguire questa operazione aprendo la vista delle proprietà (F4) e selezionando il file SQLite.Interop.dll nella soluzione.L'unica volta in cui probabilmente si bloccherà ancora è quando si esegue l'aggiornamento a una versione più recente di SQLite e il riavvio di VS2012 quindi funziona correttamente per me.

Answer 4

Il workaround provided by Philipp Aumayr (impostata CopyToOutputDirectory opzione per PreserveNewest piuttosto che il default Always) funziona per la maggior parte degli scenari, ma non tutti, purtroppo. Come altre domande su SO sottolineano, il fatto che vstest.executionengine does not terminate sia un problema comune in VS2012 - peggio ancora, gli sviluppatori Microsoft considerano questa come una funzione e dal progetto. L'opzione per prevenire questo comportamento esisteva in VS2010 ma è stata rimossa in VS2012.

Se anche tu hai un problema con questo "miglioramento", per favore vota sul problema di supporto Microsoft Connect vstest.executionengine.x86.exe (32 bit) - Not Closing (riguarda sia x86 che x64 nonostante il titolo).

Answer 5

ho lavorato intorno a questo utilizzando il seguente come un evento pre-compilazione sui progetti di test colpite:

a 64 bit:

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

o 32 bit:

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

Questo silenziosamente uccide il motore di esecuzione prima di creare il progetto di test. Il /FI "MEMUSAGE gt 1" interrompe il comando (e quindi la compilazione) dall'avaria se il motore di esecuzione non è in esecuzione.

Answer 6

In Visual Studio 2013 - Andare a "Test> Impostazioni di prova> mantenere Esecuzione del motore di esecuzione del test" e deselezionarlo! Per me va bene.

Answer 7

Provare a smaltire il collegamento come di seguito. Ha funzionato bene per me.

private void Dispose(bool disposing) 
    { 
     if (_disposed) return; 

     if (disposing) 
     { 
      if (_dbConnection != null) 
      { 
       _dbConnection.Cancel(); 
       _dbConnection.Close(); 
       _dbConnection.Dispose(); 
      } 
     } 

     _disposed = true; 
    } 

Answer 8

So che questa domanda è vecchio, ma ho avuto questo problema e alcune delle risposte qui scatenato un'idea. Uno dei primi problemi che ho incontrato durante il tentativo di creare test di unità/integrazione attorno a SQLite è stato che MSTest (che usiamo per i build con script) non stava implementando tutte le dipendenze necessarie nella directory "Out" dell'esecuzione di test prima di eseguire il test, quindi i test fallirono. Il modo migliore che ho trovato per risolvere questo problema è stato quello di aggiungere questi attributi al mio classe di test:

[TestClass] 
**[DeploymentItem("System.Data.SQLite.dll")] 
[DeploymentItem("x86\\SQLite.Interop.Dll")]** 
public class TestClass 

Questo sembra risolvere anche questo problema ... Sto indovinando questo provoca VSTest per caricare una copia diversa di questi dipendenze in modo che VSBuild possa continuare a fare ciò che vuole con la copia nella normale directory/bin /.