No se puede cargar la DLL 'SQLite.Interop.dll'


205

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?


2
Sí, está configurado para copiar siempre. Tengo carpetas x64 y x86 en bin / debug. Y funciona principalmente, pero a veces simplemente deja de funcionar. Probablemente algo esté bloqueando el acceso a la dll, intentaré descubrirlo la próxima vez que deje de funcionar. Como dije, puede funcionar días sin ningún problema.
xll

13
Obtuve este error inmediatamente después de agregar el paquete nuget de SQLite a un nuevo proyecto de consola. Copiar manualmente SQLite.Interop.dll desde la carpeta x86 hasta un nivel permite que la aplicación se ejecute. Me parece extraño que esto esté tan roto.
lesscode

@Wayne Sí, esto definitivamente ayuda. Pero en mi caso, estamos trabajando juntos en el proyecto, y mi amigo está usando x86, mientras que yo x64 OS. Y como noté, a veces simplemente deja de funcionar. Aunque no me pasó el mes pasado.
xll

1
Si descarga el binario correcto para SQLite, copie SQLite.Interop.dll en su carpeta Release o Debug de acuerdo con la opción de compilación de su proyecto.
Elshan

Este es un error tan aleatorio ... a veces ocurre y otras no para mi proyecto. Probé todo.
BK

Respuestas:


141

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.


11
Funcionó para mí después de agregar la referencia a SQLite Core con NuGet al proyecto principal.
Luca Cremonesi

Agregar sqllite.core al proyecto principal funcionó para mí en mi solución WPF
Dipu Raj el

Tuve que hacer tanto Install-package Sqlite como Install-Package System.Data.SQLite.Core en mi sitio web a pesar de que las llamadas db están en una biblioteca ...

Esta debería ser la respuesta.
Bobby Turkalino

44
¿Qué quieres decir con proyecto "sitio principal"? En mi caso estoy haciendo trabajo de escritorio. ¿Te refieres al proyecto "startup"?
UuDdLrLrSs

60

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.


Trabajó para mi ! Gracias
Tristan Djahel

Convenido. Estoy usando el paquete 'Sqlite.Net PCL' pero descubrí que también necesitaba 'System.Data.SQLite Core (x86 / x64)'. También tuve que cambiar el (los) proyecto (s) haciendo referencia a él para usar un objetivo de Plataforma de 'x86' o 'x64', en lugar de 'Cualquier CPU'.
Andrew Stephens

2
Intenté bastantes soluciones publicadas aquí, esta realmente funcionó mejor.
Batman el

2
¿Cómo puedes agregar una dependencia como esa? nunca lo hizo (VS2013)
jpgrassi

3
Vaya a Herramientas -> Administrador de paquetes NuGet -> Administrar paquetes NuGet para la solución ... -> En línea -> Todos. Luego busque sqlite y agregue System.Data.SQLite Core (x86 / x64).
Marin

44

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>

Estoy usando VS 2010, no existe tal opción.
xll

@xll, edité la respuesta para aclararla. Comprueba si la edición aclara las cosas.
Caleb Kiage

10
En VS2012 esta opción está en gris para mí.
Kugel

66
La opción solo está habilitada en proyectos EXE, pero creo que la mayoría de nosotros tenemos este problema con los proyectos de prueba unitaria.
Brannon

1
Estaba en gris para mí en un proyecto WPF en VS Pro 2015. El .csprojarchivo ya estaba configurado false, pero aún tenía el error.
vapcguy

32

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.


<itemgroup> para "SQLite.Interop.dll" no está allí en el archivo .csproj del proyecto. todavía intenté agregar su solución pero no funcionó :(
ayc

Esto no funcionará en VS2012, los elementos no existen.
htm11h

Muchas gracias. Funciona en 2015 vs.
Jevgenij Kononov

29

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.


10
ContentSQLiteInteropFiles es la respuesta. La mayoría de las respuestas principales son conjeturas.
Corey Alix

66
Sí, ContentSQLiteInteropFiles es la respuesta. 1. Esta debería ser la respuesta aceptada 2. Por otro lado, debería investigarse que, como paquete nuget, cómo hacer que esto funcione automáticamente, o al menos documentar la necesidad de esta configuración.
gerleim

Debería ser la respuesta aceptada. Súper simple 1. descargue el proyecto 2. agregue lo anterior a csproj 3. vuelva a cargar el proyecto. es así de fácil ...
BillRuhl

24

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.


1
El mensaje que recibí me decía que faltaban esos archivos, pero pensé que era un problema de permiso. Una vez que vi su mensaje, me di cuenta de que en realidad nunca llegaron al servidor cuando lo implementé.
Stradas

1
Mi solución casi idéntica fue agregar carpetas x86 y x64 a mi proyecto de inicio, luego agregar los archivos de interoperabilidad x86 y x64 dentro de sus respectivas carpetas. Configuré la opción de los archivos en "contenido" y "compilar siempre". Esta es la única forma en que puedo hacer que mi aplicación Windows Forms se conecte a un archivo de base de datos s3db incrustado cuando implementé la aplicación con ClickOnce en otras PC. Frustrantemente, no tuve un error de SQLite cuando desarrollé y probé la aplicación en mi PC.
David Alan Condit

Sigue sucediendo con VS 2017: '(
wmebane

1
Esta es la respuesta que me ayuda a entender mi problema, aunque mi solución es un poco diferente. Mi problema es que agregué el system.data.Sqlite.dll manualmente. De esta forma, Sqlite.Interop.dll no se copia automáticamente en \ x86 y x64. La solución es eliminar la referencia y agregarla por Nuget.
Susan Wang

19

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.


1
Esta solución solo funciona si está utilizando el espacio de nombres Microsoft.VisualStudio.TestTools.UnitTesting
sapbucket el

44
Esta es una solución correcta si está utilizando MSTest. SQLite funcionó bien, encontrando el SQLite.Interop.dll sin problemas, hasta que usé DeploymentItem ("some.csv") para una prueba. La inclusión del archivo .csv de esa manera activó MSTest para copiar todos los archivos DLL referenciados en el directorio TestResults. Dado que SQLite.Interop.dll no está referenciado en el proyecto (y no puede serlo porque es un código no administrado), nunca se copió.
Johann

Su mejor opción es agregar dos líneas, una para cada arquitectura. Eso lo protege en caso de que el corredor de prueba esté ejecutando 64 bits.
Kirk Woll

13

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


Si obtiene un error al hacer esto, eliminar mis DLL / referencias de SQLite y reinstalarlas completamente desde nuget fue el truco para mí
KayakinKoder

reinstalar sqllite core help para mí también. Ocurrido en VS2012. VS no incluyó la versión x62 para el paquete de implementación web
Andrey R

Solucionado también para mí en VS2015 Professional.
Rahul Kishore

9

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.


1
esta fue la única solución que funcionó para mí ... y vaya ... fue un problema depurar cuando su aplicación se cierra en la PC de un usuario.
estoico

8

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.


6

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

4

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


Muchas gracias por esto, probé todo lo demás y esta fue la solución
David Benko

4

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

Despliegue de aplicaciones

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.


3

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.



3

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


3

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.


El nombre de la carpeta debe ser costura32, documentación github.com/Fody/Costura#native-libraries-and-preloadorder
Elton Saunders

3

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


2

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).


Si. Este también fue mi caso ... solo el mío requería SP1 redistribuible de Visual C ++ 2010. La mejor solución es leer cuidadosamente qué tiempo de ejecución se requiere para su versión. Por ejemplo aquí: system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
Velja Radenkovic


2

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.


2

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.


2

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

Tuve que otorgar permisos de edición IIS_APPPOOL al archivo Bin para resolver el problema. Solo copiar el ddl estaba causando un acceso denegado al dll
AlexanderD

Agregar estos archivos ha resuelto los problemas, pero esta es una solución temporal.
Kartik Goyal

2

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

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.


1
Si bien este enlace puede responder la pregunta, es mejor incluir las partes esenciales de la respuesta aquí y proporcionar el enlace como referencia. Las respuestas de solo enlace pueden volverse inválidas si la página vinculada cambia. - De la opinión
Robert Columbia

En mi caso, el archivo testsettings es incorrecto: <TestSettings ... <Deployment> <DeploymentItem filename = "bin \ Relase \ a.test.dll". la ubicación del archivo está mal configurada.
Tony Sun

2

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.


2

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.


1

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".


1

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"?


1

¿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


1

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í.


1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.