c# - setup - SQLite.Interop.dll bloqueado después de ejecutar las pruebas de Visual Studio 2012 Unit Test Framework

sqlite visual studio 2008

Question

• Visual Studio 2012
• SQLite 1.0.82.0 (desde nuget)

Estoy tratando de usar el comando "Ejecutar todo" en el "Explorador de pruebas". El siguiente error ocurre después de ejecutar la prueba una vez ... después de eso ya no se construirá, hasta que reinicie Visual Studio.

Aquí está el error de compilación

El Proceso no puede acceder al archivo ''SQLite.Interop.dll'' porque está siendo usado por otro proceso

aquí está el código

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

Lo he intentado, cerrando la conexión, llamando a ClearAllPools, GC.Collect y creando SQLiteConnection directamente (en lugar de Factory) ... sigue siendo el mismo problema

Esto FUNCIONA si DEBUGA TODAS LAS PRUEBAS ... pero es cuando acaba de ejecutar las pruebas que esto parece bloquearlo

Answer 1

En Visual Studio 2013: vaya a "Prueba> Configuraciones de prueba> mantener el funcionamiento del motor de ejecución de prueba" y deseleccione! Funciona para mi.

Answer 2

Intente deshacerse de la conexión de la siguiente manera. Funcionó bien para mí.

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

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

        _disposed = true;
    }

Answer 3

La solución proporcionada por Philipp Aumayr (establecer la opción CopyToOutputDirectory en PreserveNewest lugar del valor predeterminado Always ) funciona para la mayoría de los escenarios, pero no para todos, desafortunadamente. Como señalan otras preguntas sobre SO, el hecho de que vstest.executionengine no finalice es un problema común en VS2012; peor aún, los desarrolladores de Microsoft tratan esto como una característica y por diseño . La opción para evitar este comportamiento existía en VS2010 pero se eliminó en VS2012.

Si usted también tiene un problema con esta "mejora", vote sobre el problema de soporte de Microsoft Connect vstest.executionengine.x86.exe (32 bits) - No cierre (afecta tanto a x86 como a x64 a pesar del título).

Answer 4

No pude encontrar esa opción en VS2012 (al menos no para pruebas unitarias estándar), por lo que se me ocurrió otra solución:

El problema al que se enfrenta proviene del hecho de que el corredor de prueba de la unidad permanece cargado, por lo que las ejecuciones de prueba repetidas son más rápidas. Como SQLite.Interop.dll probablemente no cambie con demasiada frecuencia, cambié la opción CopyToOutputDirectory a PreserveNewest lugar de la predeterminada Always .

Puede hacer esto abriendo la vista de propiedades (F4) y seleccionando el archivo SQLite.Interop.dll en su solución. Es probable que la única vez que se bloquee es cuando actualiza a una versión más nueva de SQLite y reinicia VS2012 y luego funciona bien para mí.

Answer 5

Prueba esto:

• En VS.NET, haga clic en Herramientas / Opciones
• Cuando aparezca el diálogo, haga clic en "Herramientas de prueba"
• Haga clic en "Ejecución de prueba"
• Desmarque la casilla "Mantener el motor de ejecución de prueba funcionando entre pruebas"
• Haga clic en Aceptar y reinicie VS.NET

Debería poder ejecutar pruebas basadas en SQLite ahora sin tener que reiniciar.

Answer 6

Resolví esto al usar lo siguiente como un evento previo a la compilación en los proyectos de prueba afectados:

para 64 bits:

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

o para 32 bits:

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

Esto mata silenciosamente el motor de ejecución antes de construir el proyecto de prueba. El /FI "MEMUSAGE gt 1" impide que el comando (y por lo tanto la compilación) falle si el motor de ejecución no se está ejecutando.

Answer 7

Sé que esta pregunta es antigua, pero tuve este problema y algunas de las respuestas aquí provocaron una idea. Uno de los primeros problemas que encontré al intentar crear pruebas de unidad / integración alrededor de SQLite fue que MSTest (que utilizamos para compilaciones con script) no estaba implementando todas las dependencias necesarias para el directorio "Out" de la ejecución de la prueba antes de ejecutar la prueba. así que las pruebas fallaron. La mejor manera que encontré para resolver este problema fue agregar estos atributos a mi clase de prueba:

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

Esto parece resolver también este problema ... Supongo que esto hace que VSTest cargue una copia diferente de estas dependencias para que VSBuild pueda hacer lo que hará con la copia en su directorio / bin / normal.

Answer 8

También asegúrese de que su base de datos está instalada en la carpeta correcta
Cadenas de conexión SQLite

Adaptador de datos que también puede probar con SQL Lite usando SQLitew con .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);
}

Lea este artículo para ver si ayuda a corregir su problema, así como System.Data.SQLite.View Ticket