Periódicamente recibo la siguiente excepción:

Unable to load DLL 'SQLite.Interop.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Estoy usando 1.0.82.0. versión, instalándolo con nuget en VS2010, OS Win7 64.

Una vez que la excepción comienza a aparecer, aparece constantemente: en depuración y lanzamiento y ejecución de aplicaciones dentro o fuera de VS.

La única forma de detenerlo es cerrar sesión e iniciar sesión. La excepción no se produce y se carga dll. Puede funcionar durante días, pero luego puede romperse nuevamente.

¿Alguien ha visto algo como esto y hay una solución para ello?

Sé que llego tarde a la fiesta, pero tuve este problema justo después de que saqué el último x86 / x64 hoy (versión 1.0.88.0). Mi IIS local en VS2012 ejecuta 32 bits por defecto y no hay una manera fácil de cambiar a x64. Mi servidor de producción funciona con 64 bits.

De todos modos instalé el paquete NuGet en un proyecto DLL y recibí este error. Lo que tuve que hacer para que funcionara también tuve que instalarlo en el proyecto del sitio principal . Incluso si no toca las clases de SQLite en absoluto.

Supongo que SQLite usa el ensamblado de entrada para detectar qué versión de Interop cargar.

Tuve este problema porque un dll que estaba usando tenía Sqlite como dependencia (configurado en NuGet con solo el paquete central de Sqlite). El proyecto compila y copia todos los dll-s de Sqlite excepto el 'SQLite.Interop.dll' (carpeta x86 y x64).

La solución fue muy simple: simplemente agregue el paquete Sqlite.Core como una dependencia (con NuGet) al proyecto que está creando / ejecutando y se copiarán los dll-s.

Tuve este mismo problema al usar SQLite en un proyecto WPF cuyo objetivo de plataforma era Any CPU. Lo arreglé siguiendo los siguientes pasos:

1. Abra el diseñador del proyecto en Visual Studio. Los detalles sobre cómo hacerlo se pueden encontrar aquí .
2. Haga clic en la pestaña Construir.
3. Deshabilita la prefer 32-bitopción.

Alternativamente, puede establecer el objetivo de la plataforma en x86o x64. Creo que este problema es causado por elSystem.Data.SQLite biblioteca que usa el objetivo de la plataforma para obtener la ubicación del archivo 'SQLite.Interop.dll'.

ACTUALIZAR:

En caso de que no se pueda acceder al diseñador del proyecto, simplemente abra el *.csprojarchivo project ( ) desde un editor de texto y agregue el valor <Prefer32Bit>false</Prefer32Bit>a la <PropertyGroup>...</PropertyGroup>etiqueta.

Código de ejemplo

<PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>[Set by Visual Studio]</ProjectGuid>
    <OutputType>Exe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>[Set by Visual Studio]</RootNamespace>
    <AssemblyName>[Set by Visual Studio]</AssemblyName>
    <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
    <FileAlignment>[Set by Visual Studio]</FileAlignment>
    <!--Add the line below to your project file. Leave everything else untouched-->
    <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>

Así es como lo arreglé en mi proyecto.

Estaba funcionando, y cuando un colega envió sus cambios, recibí la excepción "No se puede cargar la DLL 'SQLite.Interop.dll'".

Difundiendo el archivo .csproj del proyecto, esto estaba en la versión que NO FUNCIONA:

<ItemGroup>
     <Content Include="x64\SQLite.Interop.dll" />
     <Content Include="x86\SQLite.Interop.dll" />
</ItemGroup>

Y esto es lo que tenía la versión WORKING:

<ItemGroup>
     <Content Include="x64\SQLite.Interop.dll">
          <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      </Content>
      <Content Include="x86\SQLite.Interop.dll">
          <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      </Content>
</ItemGroup>

Después de volver atrás, no recibí la excepción. Los archivos DLL se volcaron en las carpetas Debug \ x64 (etc.) apropiadas.

Entonces, después de agregar NuGet, la implementación no copia Interops. Puede agregar esto a su archivo csproj y debería corregir ese comportamiento:

 <PropertyGroup> 
    <ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles>
    <CopySQLiteInteropFiles>false</CopySQLiteInteropFiles>
    <CleanSQLiteInteropFiles>false</CleanSQLiteInteropFiles>
    <CollectSQLiteInteropFiles>false</CollectSQLiteInteropFiles>
 </PropertyGroup>

Si busca en la fuente NuGet para SQLite, puede ver qué están haciendo específicamente. Esto me permitió realizar un despliegue trabajando con ASP.Net Core.

Cuando llegue a este estado, intente realizar una Reconstrucción de todo. Si esto soluciona el problema, es posible que tenga el mismo problema que tuve.

Algunos antecedentes (mi entendimiento) :

• SQLite tiene 1 ensamblado administrado (System.Data.SQLite.dll) y varios ensamblados específicos de plataforma (SQLite.Interop.dll). Al instalar SQLite con Nuget, Nuget agregará los ensamblados específicos de la plataforma a su proyecto (dentro de varias carpetas: \ x86, \ x64) y configurará estos dlls para "Copiar siempre".

• Tras la carga, el ensamblado administrado buscará ensamblados específicos de la plataforma dentro de las carpetas \ x86 y \ x64. Puedes ver más sobre eso aquí . La excepción es este ensamblado administrado que intenta encontrar el relevante (SQLite.Interop.dll) dentro de estas carpetas (y falla).

Mi escenario :

Tengo 2 proyectos en mi solución; una aplicación WPF y una biblioteca de clases. La aplicación WPF hace referencia a la biblioteca de clases, y la biblioteca de clases hace referencia a SQLite (instalado a través de Nuget).

El problema para mí fue que cuando modifico solo la aplicación WPF, VS intenta hacer una reconstrucción parcial (dándose cuenta de que el dll dependiente no ha cambiado). En algún lugar de este proceso, VS limpia el contenido de las carpetas \ x86 y \ x64 (eliminando SQLite.Interop.dll). Cuando hago una reconstrucción completa, VS copia correctamente las carpetas y su contenido.

Mi solución :

Para solucionar esto, terminé agregando un proceso posterior a la compilación usando xcopy para forzar la copia de las carpetas \ x86 y \ x64 de la biblioteca de clases a mi directorio de proyecto WPF \ bin.

Alternativamente, podría hacer cosas más sofisticadas con los directorios de configuración / salida de compilación.

Tuve el mismo problema al ejecutar Visual Studio Express 2013. Probé varias soluciones mencionadas aquí y en otros lugares en vano. Espero que esta solución ayude a otros.

Lo arreglé usando el DeploymentItematributo en mi clase de prueba que prueba el servicio basado en SQLite.

Ejemplo:

[TestClass]
[DeploymentItem(@"x86\SQLite.Interop.dll", "x86")] // this is the key
public class LocalStoreServiceTests
{

    [TestMethod]
    public void SomeTestThatWasFailing_DueToThisVeryIssue()
    {
         // ... test code here
    }
}

Esto hace que lo necesario SQLite.Interop.dllse copie en elx86 directorio dentro de la carpeta "TestResults" apropiada.

Todo es verde Todo es bueno.

Actualizar NuGet desde Tools -> Extension and updatesy reinstalar SQLite.Core con el comando lo PM> Update-Package -reinstall System.Data.SQLite.Corearregló para mí.

Tuve un problema similar en una solución de proyectos múltiples. El SQLite.Interop.dll era necesario para uno de los complementos distribuidos con el software usando ClickOnce.

En cuanto a la depuración en Visual Studio, todo funcionó bien, pero a la versión implementada le faltaban las carpetas x86 / y x64 / que contenían esa DLL.

La solución para que funcione después de la implementación con ClickOnce fue crear en el proyecto de inicio de la solución (también la que se está publicando) estas dos subcarpetas, copiar en ellas las DLL y configurarlas como Content Copy Always.

De esta forma, la herramienta de publicación ClickOnce incluye automáticamente estos archivos y carpetas en el manifiesto e implementa el software con ellos.

Realmente hay muchas respuestas aquí, pero la mía es simple y clara sin jugar con GAC .

El problema era que el archivo ejecutable necesita una copia del derecho SQLite.Interop.dll(x86 o x64) para acceder a nuestra base de datos.

La mayoría de las arquitecturas tienen capas y, en mi caso, la capa de datos tiene la DLL requerida para la conexión SQLite.

Así que simplemente puse un script posterior a la compilación en mi solución de capa de datos y todo funcionó bien.

TL; DR;

1. Establezca todos los proyectos de su solución en x86o x64en las opciones de compilación.

2. Agregue lo siguiente Post-Build-Scriptal Proyecto con SQLite nuget Package:

   xcopy "$(TargetDir)x64" "$(SolutionDir)bin\Debug\" /y

Por supuesto, debe cambiar el script Release Buildy las x86compilaciones.

STL; DR;

Pon tu al SQLite.Interop.dlllado del *.exearchivo.

La instalación predeterminada de la versión de arquitectura múltiple (x86, x64) de SQLite de NuGet exhibe el comportamiento que usted describió. Si desea cargar la versión correcta para la arquitectura real que el tiempo de ejecución de .NET eligió para ejecutar su aplicación en su máquina, puede darle al cargador de DLL una pista sobre dónde ubicar la biblioteca correcta de la siguiente manera:

Agregue una declaración para la llamada a la función kernel32.dll a SetDLLDirectory () antes de su Program.Main ():

    [System.Runtime.InteropServices.DllImport("kernel32.dll", CharSet = System.Runtime.InteropServices.CharSet.Unicode, SetLastError = true)]
    [return: System.Runtime.InteropServices.MarshalAs(System.Runtime.InteropServices.UnmanagedType.Bool)]
    static extern bool SetDllDirectory(string lpPathName);

Luego use su propio método para determinar el subdirectorio correcto para encontrar la versión específica de la arquitectura de 'SQLite.Interop.dll'. Yo uso el siguiente código:

    [STAThread]
    static void Main()
    {
        int wsize = IntPtr.Size;
        string libdir = (wsize == 4)?"x86":"x64";
        string appPath = System.IO.Path.GetDirectoryName(Application.ExecutablePath);
        SetDllDirectory(System.IO.Path.Combine(appPath, libdir));

incluso si es una publicación anterior, me gustaría compartir la solución que encontré aquí: http://system.data.sqlite.org/index.html/info/54e52d4c6f

Si no desea leer todo el problema, la solución es copiar el archivo "msvcr100.dll" (que se puede encontrar en el directorio Windows \ System32) en la misma ruta que SQLite.Interop.dll.

Le recomendaría leer el problema para comprender por qué, e incluir el archivo en su configuración, pero para instalarlo solo si se produce el error, lo convertí en un componente opcional seleccionable en las opciones de configuración.

HTH, Formentz

Como dice el wiki de SQLite , la implementación de su aplicación debe ser:

Entonces debes seguir las reglas. Encuentre dll que coincida con su plataforma de destino y colóquelo en la ubicación, se describe en la imagen. Dlls se puede encontrar en YourSolution / packages / System.Data.SQLite.Core.% Version% /.

Tuve problemas con la implementación de la aplicación, por lo que acabo de agregar SQLite.Interop.dll correcto en mi proyecto, la carpeta x86 agregada a AppplicationFolder en el proyecto de instalación y agregué referencias de archivo a dll.

También podría obtener este error si está intentando ejecutar un dll de 32 bits, en un proyecto de 64 bits.

Obtuve esto cuando coloqué el mismo archivo (SQLite.Interop.dll en la versión de 32 bits) en la carpeta x86 y x64.

Si descarga el binario correcto para SQLite, cópielo SQLite.Interop.dllen su carpeta Release o Debug de acuerdo con la opción de compilación de su proyecto.

No sé por qué esto aún no se ha incluido, pero tuve que investigar y descubrirlo por mí mismo, así que espero que alguien encuentre esta respuesta y se salve el problema. Esto fue para una aplicación WPF. Funcionó bien en mi caja Dev, pero no funcionó en la computadora donde la estaba copiando y obtuve el Unable to load DLL 'SQLite.Interop.dll'error. Trasporté todos sus directorios y archivos asociados, directamente desde mi carpeta "Debug" a esta otra computadora cuando recibí el mismo error que el OP cuando lo ejecuté. Mi carpeta "bin" que contenía mis archivos DLL se había copiado en "Debug \ bin" y se incluyeron todos, junto con mis archivos de aplicación cuando hice mi copia a la otra computadora usando esta ruta, por lo que no faltaba ningún archivo.

Las cosas que vi dijeron en otras respuestas que no se aplicaban:

• No utilicé el paquete NuGet ni necesité crear carpetas x86 o x64 que parece que crea el paquete NuGet. Mis archivos DLL (System.Data.SQLite y SQLite.Interop.dll, junto con System.Data.SQLite.config) están en la carpeta "bin" de mi proyecto y se copiaron manualmente (crear la carpeta "bin" en el Explorador de soluciones en VS, pegue las DLL en esta carpeta en el Explorador de Windows, use Agregar> Elemento existente para llevar los archivos a la carpeta / proyecto VS). Luego los hago referencia como Ensambles a los que se hace referencia en mi proyecto usando esa ubicación ("Referencias"> "Agregar referencia", y busco uno, enjuague, repita el resto). Esto garantiza que mi proyecto sepa exactamente dónde están.
• No necesitaba hacer referencia a ningún archivo DLL de SQLite en mi app.config ni siquiera tocar mi archivo MyProject.csproj.
• ¡Ni siquiera necesitaba especificar un procesador en particular! La compilación de mi proyecto es para "Cualquier CPU", a pesar de que solo tengo DLL mixtas o de 64 bits y solo se ejecutará en Windows 7+, que son sistemas operativos de 64 bits. (sin DLL solo x86 / 32 bits únicamente)
• Ya los estaba especificando como "Contenido" y "copiar si es más reciente" para estas DLL cuando experimenté el error del OP.

Lo que encontré fue esto, de https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20 :

(11) ¿Por qué obtengo una DllNotFoundException (para "sqlite3.dll" o "SQLite.Interop.dll") cuando intento ejecutar mi aplicación?

La biblioteca de enlaces dinámicos (DLL) nombrada no se puede ubicar o no se puede cargar debido a la falta de dependencias. Asegúrese de que la biblioteca de enlaces dinámicos con nombre esté ubicada en el directorio de la aplicación o en un directorio a lo largo de la RUTA del sistema e intente nuevamente. Además, asegúrese de que se haya instalado el tiempo de ejecución necesario de Visual C ++ redistribuible a menos que esté utilizando una biblioteca de enlaces dinámicos que se creó estáticamente vinculada a ellos.

El énfasis es mío en esa parte en negrita dentro del párrafo. La computadora de destino era nueva y no tenía programas cargados excepto .NET 4.0. Una vez que instalé C ++, pude completar los comandos para SQLite. Esta debería haber sido una de las primeras preguntas frecuentes y parte de los requisitos previos, pero fue enterrada en el n. ° 11. Mi computadora de desarrollo ya la tenía cargada porque venía con Visual Studio, por eso funcionó allí.

Descargar:
Visual C ++ Redistributable para Visual Studio 2015:
https://www.microsoft.com/en-us/download/details.aspx?id=48145

Actualización 3 (actualización acumulativa):
https://www.microsoft.com/en-us/download/details.aspx?id=53587

He comenzado a usar Costura.Fody para empaquetar (.net) ensamblajes e incrustar y precargar dlls nativos. Esto también ayuda más adelante, con la distribución, ya que puede enviar un archivo.

1. Instala Costura Fody desde Nuget.

2. En su proyecto C #, cree una carpeta llamada costrua32. Allí agregue cualquier dlls nativo que C # cargar.

3. Una vez que los haya agregado a esta carpeta. Haga clic en la ventana de propiedades y cambie la acción de compilación a "Recurso incorporado"

4. Finalmente, necesita modificar el archivo XML llamado FodyWeavers.xml de la siguiente manera. Aquí estoy especificando cargar el dll sql primero. (tenga en cuenta que suelta el .dll)

   Weavers
    Costura
     PreloadOrder
      SQLite.Interop
      tbb_debug
      tbb
     /PreloadOrder>
    /Costura
   /Weavers

La ventaja de esto es que no tiene que escribir ningún evento previo o posterior a la compilación, y el producto final está totalmente encapsulado en un archivo más grande.

También agregó el dll al proyecto de prueba (a través de Nuget Manager) y lo arregló.

Tuve este problema porque Visual C ++ 2010 redistribuible no está instalado en mi PC. Si aún no ha instalado Visual c ++ 2010 redistributable Descargue e instale esto (verifique x86 o 64 dll).

Tengo el mismo problema. Sin embargo, finalmente, puedo arreglarlo. Actualmente, uso Visual Studio 2013 Community Edition. Solo uso Agregar-> Elemento existente ... y busco dónde están los archivos SQLite.Data.SQLite (mi caso es 'C: \ Archivos de programa (x86) \ System.Data.SQLite \ 2013 \ bin'). No olvide cambiar el tipo de lo que incluirá en Archivos de ensamblaje (* .dll; * .pdb) . Elija ' SQLite.Interop.dll ' en esa carpeta. A partir de ahí, puedo continuar sin ningún problema. Buena suerte a todos ustedes. ^ _ ^ PD. Creo una aplicación de formulario web. No lo he probado en la aplicación de formulario de ventana u otros todavía.

Intente establecer el objetivo de la plataforma en x86 o x64 (y no en cualquier CPU) antes de compilar: Proyecto-> Propiedades-> Compilar-> Destino de plataforma en Visual Studio.

Copie SQLite.Interop.dll en el directorio del proyecto.

src\
  project\
      bin\   <-- Past in bin
         x64\
           SQLite.Interop.dll <-- Copy this if 64
         x86\
           SQLite.Interop.dll <-- Copy this if 32

He luchado con esto durante mucho tiempo y, ocasionalmente, descubrí que la configuración de prueba es incorrecta. Ver esta imagen:

Acabo de desmarcar la configuración de prueba y el problema desaparece. De lo contrario, se producirá la excepción. Espero que esto ayude a alguien. No estoy seguro de que sea la causa raíz.

Copie los archivos "SQLite.Interop.dll" para x86 y x64 en la carpeta de depuración. estos archivos deben copiarse en las carpetas "x86" y "x64 en la carpeta de depuración.

Mi aplicación es una aplicación web (ASP.NET MVC) y tuve que cambiar el grupo de aplicaciones para ejecutar en LocalSystemlugar de ApplicationPoolIdentity. Para hacer esto:

1. Abra el administrador de IIS
2. Encuentre el grupo de aplicaciones con el que se ejecuta su sitio.
3. Haga clic en Configuración avanzada de las acciones
4. Cambiar identidad a LocalSystem

No tengo idea de por qué esto soluciona el problema.

No sé si es una buena respuesta, pero pude resolver este problema ejecutando mi aplicación bajo un AppDomain con una identidad de "Sistema local".

Estoy trabajando en una aplicación de consola simple para agregar algunos datos de prueba a una base de datos SQLite y recibí este error. La configuración para el proyecto es "Cualquier CPU". Lo arreglé copiando el SQLite.Interop.dll a la carpeta bin \ debug. Una mejor manera sería utilizar el método de @Wil, pero ¿cómo se especifica esto para la configuración de "Cualquier CPU"?

¿Podría haber contención para la asamblea? Verifique si hay otra aplicación con un bloqueo de archivo en la DLL.

Si esta es la razón, debería ser fácil usar una herramienta como el Explorador de procesos de Sysinternal para descubrir el programa ofensivo.

HTH, arcilla

Como referencia para cualquiera que esté mirando esta pregunta:

Si usa el paquete nuget, instala una regla de compilación que hace la copia por usted. (consulte la sección System.Data.SQLite.Core.1.0.94.0 \ build, o cualquier versión de Core que instale).

El instalador nuget agrega la regla a su archivo de proyecto automáticamente.

Sin embargo, esto todavía no soluciona el problema del caso de prueba. El enfoque DeploymentItem ( https://stackoverflow.com/a/24411049/89584 ) es lo único que parece funcionar allí.

Me encontré con este problema, en una solución con un proyecto web WebAPI / MVC5 y un proyecto de prueba de características, que derivaron del mismo proyecto de acceso a datos (o 'Core'). Yo, como tantos otros aquí, estoy usando una copia descargada a través de NuGet en Visual Studio 2013.

Lo que hice fue que en Visual Studio agregué una carpeta de solución x86 y x64 a la Prueba de características y Proyectos web. Luego hice un Right Click | Add Existing Item..., y agregué la biblioteca SQLite.interop.dll apropiada ..\SolutionFolder\packages\System.Data.SQLite.Core.1.0.94.0\build\net451\[appropriate architecture]para cada una de esas carpetas. Entonces hice un Right Click | Properties, y me puse Copy to Output Directorya Always Copy. La próxima vez que necesitaba ejecutar mis pruebas de características, las pruebas se ejecutaron con éxito.