Periodicamente ricevo la seguente eccezione:

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

Sto usando 1.0.82.0. versione, installandolo con nuget in VS2010, OS Win7 64.

Una volta che l'eccezione inizia a comparire, appare costantemente - nel debug e nel rilascio e nell'esecuzione dell'applicazione dentro o fuori VS.

L'unico modo per fermarlo è la disconnessione e l'accesso. L'eccezione non viene generata e la dll viene caricata. Può funzionare per giorni, ma poi può rompersi di nuovo.

Qualcuno ha visto qualcosa del genere e c'è una soluzione per questo?

So di essere in ritardo alla festa, ma ho avuto questo problema subito dopo aver rimosso l'ultimo x86 / x64 oggi (versione 1.0.88.0). Il mio IIS locale in VS2012 esegue 32 bit per impostazione predefinita e non esiste un modo semplice per passare a x64. Il mio server di produzione funziona a 64 bit.

Comunque ho installato il pacchetto NuGet in un progetto DLL e ho riscontrato questo errore. Quello che dovevo fare per farlo funzionare, dovevo installarlo anche sul progetto del sito principale . Anche se non tocca affatto le classi SQLite.

La mia ipotesi è che SQLite utilizzi l'assembly entry per rilevare quale versione di Interop caricare.

Ho avuto questo problema perché una dll che stavo usando aveva Sqlite come dipendenza (configurata in NuGet con solo il pacchetto core Sqlite.). Il progetto compila e copia tutte le dll-s Sqlite ad eccezione di "SQLite.Interop.dll" (cartella x86 e x64).

La soluzione era molto semplice: basta aggiungere il pacchetto Sqlite.Core come dipendenza (con NuGet) al progetto che si sta costruendo / in esecuzione e le DLL verranno copiate.

Ho avuto lo stesso problema durante l'utilizzo di SQLite in un progetto WPF il cui obiettivo di piattaforma era Any CPU. L'ho risolto seguendo i seguenti passi:

1. Apri il progettista del progetto in Visual Studio. I dettagli su come farlo possono essere trovati qui .
2. Fai clic sulla scheda Genera.
3. Disabilita l' prefer 32-bitopzione.

In alternativa, puoi semplicemente impostare il target della piattaforma su x86o x64. Penso che questo problema sia causato dalla System.Data.SQLitelibreria che utilizza l'obiettivo di piattaforma per ottenere la posizione del file "SQLite.Interop.dll".

AGGIORNARE:

Nel caso in cui il progettista non possa essere raggiunto, basta aprire il *.csprojfile project ( ) da un editor di testo e aggiungere il valore <Prefer32Bit>false</Prefer32Bit>nel <PropertyGroup>...</PropertyGroup>tag.

Codice di esempio

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

È così che l'ho risolto nel mio progetto.

Stava funzionando e quando un collega ha inviato le sue modifiche, ho ricevuto l'eccezione "Impossibile caricare DLL 'SQLite.Interop.dll'".

Diffondendo il file .csproj del progetto, questo era nella versione NON FUNZIONANTE:

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

E questo è ciò che aveva la versione WORKING:

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

Dopo il ripristino, non ho ricevuto l'eccezione. I file DLL sono stati scaricati nelle cartelle Debug \ x64 (etc) appropriate.

Quindi, dopo aver aggiunto NuGet, la distribuzione non copia gli Interops. Puoi aggiungerlo al tuo file csproj e dovrebbe correggere quel comportamento:

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

Se cerchi l'origine di NuGet per SQLite puoi vedere cosa stanno facendo specificamente. Ciò mi ha permesso di ottenere una distribuzione funzionante con ASP.Net Core.

Quando arrivi in ​​questo stato, prova a eseguire un Rebuild-All. Se questo risolve il problema, potresti avere lo stesso problema che ho avuto.

Alcuni retroscena (la mia comprensione) :

• SQLite ha 1 assembly gestito (System.Data.SQLite.dll) e diversi assembly specifici della piattaforma (SQLite.Interop.dll). Quando si installa SQLite con Nuget, Nuget aggiungerà gli assiemi specifici della piattaforma al progetto (in diverse cartelle: \ x86, \ x64) e configura queste dll su "Copia sempre".

• Al caricamento, l'assembly gestito cercherà assembly specifici della piattaforma all'interno delle cartelle \ x86 e \ x64. Puoi vedere di più qui . L'eccezione è che questo assembly gestito tenta di trovare il relativo (SQLite.Interop.dll) all'interno di queste cartelle (e non riesce).

Il mio scenario :

Ho 2 progetti nella mia soluzione; un'app WPF e una libreria di classi. L'app WPF fa riferimento alla libreria di classi e la libreria di classi fa riferimento a SQLite (installato tramite Nuget).

Il problema per me era quando modifico solo l'app WPF, VS tenta di fare una ricostruzione parziale (rendendosi conto che la DLL dipendente non è cambiata). Da qualche parte in questo processo, VS pulisce il contenuto delle cartelle \ x86 e \ x64 (eliminando SQLite.Interop.dll). Quando eseguo un Rebuild-All completo, VS copia correttamente le cartelle e il loro contenuto.

La mia soluzione :

Per risolvere questo problema, ho finito per aggiungere un processo Post-Build usando xcopy per forzare la copia delle cartelle \ x86 e \ x64 dalla libreria di classi nella mia directory \ bin del progetto WPF.

In alternativa, potresti fare cose più fantasiose con le directory di configurazione / output della build.

Ho avuto lo stesso problema con Visual Studio Express 2013. Ho provato diverse soluzioni menzionate qui e altrove senza risultati. Spero che questa correzione aiuti gli altri.

L'ho corretto usando l' DeploymentItemattributo sulla mia classe di test che verifica il servizio basato su SQLite.

Esempio:

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

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

Ciò causa la necessità SQLite.Interop.dlldi essere copiato nella x86directory all'interno della cartella "TestResults" appropriata.

Tutto è verde. Va tutto bene.

L'aggiornamento di NuGet Tools -> Extension and updatese la reinstallazione di SQLite.Core con il comando lo hanno PM> Update-Package -reinstall System.Data.SQLite.Corerisolto per me.

Ho avuto un problema simile in una soluzione a più progetti. SQLite.Interop.dll era necessario per uno dei plugin distribuiti con il software utilizzando ClickOnce.

Per quanto riguarda il debug in Visual Studio, tutto ha funzionato bene, ma nella versione distribuita mancavano le cartelle x86 / e x64 / contenenti quella DLL.

La soluzione per farlo funzionare dopo la distribuzione usando ClickOnce era creare nel progetto di avvio della soluzione (anche quella che viene pubblicata) queste due sottocartelle, copiare in esse le DLL e impostarle come Content Copy Always.

In questo modo lo strumento di pubblicazione ClickOnce include automaticamente questi file e cartelle nel manifest e distribuisce il software con essi

Ci sono davvero molte risposte qui, ma la mia è semplice e chiara con no-GAC-play-around .

Il problema era che il file eseguibile necessita di una copia del diritto SQLite.Interop.dll(x86 o x64) per accedere al nostro database.

Principalmente le architetture hanno livelli e nel mio caso il livello dati ha la DLL richiesta per la connessione SQLite.

Quindi ho semplicemente inserito uno script post build nella mia soluzione di livello dati e tutto ha funzionato bene.

TL; DR;

1. Imposta tutti i progetti della tua soluzione su x86o x64nelle opzioni di creazione.

2. Aggiungi quanto segue Post-Build-Scriptal Progetto con SQLite nuget Package:

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

Ovviamente devi cambiare lo script Release Builde le x86build.

STL; DR;

Metti il ​​tuo SQLite.Interop.dllprossimo al *.exeFile.

L'installazione predefinita della versione multi-architettura (x86, x64) di SQLite da NuGet mostra il comportamento descritto. Se si desidera caricare la versione corretta per l'architettura effettiva che il runtime .NET ha scelto di eseguire l'applicazione sul proprio computer, è possibile fornire al caricatore DLL un suggerimento su dove individuare la libreria corretta come segue:

Aggiungere una dichiarazione per la chiamata della funzione kernel32.dll a SetDLLDirectory () prima di 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);

Quindi utilizzare il proprio metodo per determinare la sottodirectory corretta per trovare la versione specifica dell'architettura di "SQLite.Interop.dll". Io uso il seguente codice:

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

anche se si tratta di un vecchio post, vorrei condividere la soluzione che ho trovato qui: http://system.data.sqlite.org/index.html/info/54e52d4c6f

Se non si desidera leggere tutto il problema, la soluzione è copiare il file "msvcr100.dll" (che si trova nella directory Windows \ System32) nello stesso percorso di SQLite.Interop.dll.

Consiglio di leggere il problema per capire il perché e di includere il file nella configurazione ma di installarlo solo se si verifica l'errore, l'ho reso un componente opzionale selezionabile nelle opzioni di installazione.

HTH, Formentz

Come dice il wiki di SQLite , la distribuzione dell'applicazione deve essere:

Quindi devi seguire le regole. Trova dll che corrisponda alla tua piattaforma di destinazione e mettila in posizione, come descritto in figura. Le DLL sono disponibili in YourSolution / pacchetti / System.Data.SQLite.Core.% Version% /.

Ho avuto problemi con la distribuzione dell'applicazione, quindi ho appena aggiunto SQLite.Interop.dll giusto nel mio progetto, la cartella x86 aggiunta ad AppplicationFolder nel progetto di installazione e aggiunto riferimenti a file alla dll.

Questo errore potrebbe verificarsi anche se si sta tentando di eseguire una DLL a 32 bit, in un progetto a 64 bit.

Ho ottenuto questo quando ho inserito lo stesso file (SQLite.Interop.dll nella versione a 32 bit) sia nella cartella x86 che x64.

Se scarichi il file binario corretto per SQLitepoi copiarlo SQLite.Interop.dllnella cartella Release o Debug in base all'opzione di compilazione del progetto.

Non so perché questo non sia stato ancora incluso, ma ho dovuto fare la ricerca e scoprirlo da solo, quindi spero che qualcuno troverà questa risposta e si salverà il problema. Questo era per un'app WPF. Ha funzionato bene sulla mia casella Dev, ma non ha funzionato sul computer in cui lo stavo copiando e ho ottenuto l' Unable to load DLL 'SQLite.Interop.dll'errore. Ho eseguito il porting su tutte le directory e i file associati, direttamente dalla mia cartella "Debug" su questo altro computer quando ho ricevuto lo stesso errore dell'OP durante l'esecuzione. La mia cartella "bin" che conteneva le mie DLL era stata copiata in "Debug \ bin" e tutte erano incluse, insieme ai file delle mie applicazioni quando facevo la mia copia sull'altro computer usando questo percorso, quindi non mancavano i file.

Le cose che ho visto hanno detto in altre risposte che non si applicavano:

• Non ho usato il pacchetto NuGet né ho bisogno di creare cartelle x86 o x64 che sembra creare il pacchetto NuGet. Le mie DLL (System.Data.SQLite e SQLite.Interop.dll, insieme a System.Data.SQLite.config) si trovano nella cartella "bin" nel mio progetto e sono state copiate manualmente (creare la cartella "bin" in Esplora soluzioni in VS, incolla le DLL in questa cartella in Esplora risorse, usa Aggiungi> Elemento esistente per portare i file nella cartella / progetto VS). Quindi li faccio riferimento come Assemblee referenziate nel mio progetto usando quella posizione ("Riferimenti"> "Aggiungi riferimento", e sfogliare uno, sciacquare, ripetere per il resto). Questo assicura che il mio progetto sappia esattamente dove sono.
• Non ho avuto bisogno di fare riferimento a nessun file DLL SQLite nel mio file app.config o persino di toccare il mio file MyProject.csproj.
• Non avevo nemmeno bisogno di specificare un processore particolare! La build del mio progetto è per "Qualsiasi CPU", anche se ho solo DLL miste o a 64 bit e funzionerò solo su Windows 7+, che sono sistemi operativi a 64 bit. (nessuna DLL solo x86 / solo 32 bit)
• Li stavo già specificando come "Contenuto" e "copia se più recente" per queste DLL quando ho riscontrato l'errore dell'OP.

Quello che ho trovato è stato questo, da https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20 :

(11) Perché ricevo una DllNotFoundException (per "sqlite3.dll" o "SQLite.Interop.dll") quando provo a eseguire la mia applicazione?

Impossibile trovare la libreria a collegamento dinamico (DLL) denominata o non può essere caricata a causa di dipendenze mancanti. Assicurarsi che la libreria di collegamento dinamico denominata si trovi nella directory dell'applicazione o in una directory lungo il PERCORSO di sistema e riprovare. Inoltre, assicurarsi che sia stato installato il ridistribuibile runtime di Visual C ++ necessario, a meno che non si stia utilizzando una libreria a collegamento dinamico che è stata creata in modo statico.

Sottolinea il mio su quella parte in grassetto all'interno del paragrafo. Il computer di destinazione era aggiornato e non aveva programmi caricati tranne .NET 4.0. Una volta installato C ++, è stato in grado di completare i comandi su SQLite. Questa dovrebbe essere stata una delle prime FAQ e parte dei pre-requisiti, ma è stata sepolta al numero 11. Il mio computer di sviluppo lo aveva già caricato perché fornito con Visual Studio, quindi è per questo che ha funzionato lì.

Scarica:
Visual C ++ ridistribuibile per Visual Studio 2015:
https://www.microsoft.com/en-us/download/details.aspx?id=48145

Aggiornamento 3 (aggiornamento cumulativo):
https://www.microsoft.com/en-us/download/details.aspx?id=53587

Ho iniziato a utilizzare Costura.Fody per impacchettare (.net) assembly e incorporare e precaricare DLL native. Questo aiuta anche in seguito, con la distribuzione in quanto è possibile inviare un file.

1. Installa Costura Fody da Nuget.

2. Nel tuo progetto C # crea una cartella chiamata costrua32. In là aggiungi eventuali dll native che C # carichi.

3. Dopo averli aggiunti a questa cartella. Fare clic sulla finestra delle proprietà e modificare l'azione di compilazione in "Risorsa integrata"

4. Infine, è necessario modificare il file XML chiamato FodyWeavers.xml come segue. Qui sto specificando prima caricare la sql dll. (nota che lasci cadere il .dll)

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

Il vantaggio di ciò è che non è necessario scrivere alcun evento pre o post build e il prodotto finale è totalmente incapsulato in un file più grande.

Aggiunta anche la dll al progetto di test (tramite Nuget Manager) e risolto.

Ho avuto questo problema perché Visual C ++ 2010 ridistribuibile non installato nel mio PC. Se non hai già installato Visual c ++ 2010 ridistribuibile Scarica e installa questo (controlla x86 o 64 dll).

Ho avuto lo stesso problema. Tuttavia, finalmente, posso ripararlo. Attualmente, utilizzo Visual Studio 2013 Community Edition. Io uso solo Aggiungi-> Articolo esistente ... e cerco dove sono i file SQLite.Data.SQLite (il mio caso è 'C: \ Programmi (x86) \ System.Data.SQLite \ 2013 \ bin'). Non dimenticare di cambiare il tipo di ciò che includerai in Assembly Files (* .dll; * .pdb) . Scegli " SQLite.Interop.dll " in quella cartella. Da lì in poi, posso continuare senza alcun problema. Buona fortuna a tutti voi. ^ _ ^ PS Creo un'applicazione per moduli web. Non ho ancora provato nell'applicazione per finestre o altri.

Prova a impostare la destinazione della piattaforma su x86 o x64 (e non su qualsiasi CPU) prima di creare: Progetto-> Proprietà-> Costruzione-> Destinazione piattaforma in Visual Studio.

Copia SQLite.Interop.dll nella directory del progetto.

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

Ho lottato con questo per molto tempo e, di tanto in tanto, ho scoperto che l'impostazione del test non è corretta. Vedi questa immagine:

Deseleziono le impostazioni di prova e il problema scompare. Altrimenti, si verificherà l'eccezione. Spero che questo possa aiutare qualcuno. Non sono sicuro che sia la causa principale.

Copia i file "SQLite.Interop.dll" per x86 e x64 nella cartella di debug. questi file dovrebbero essere copiati nelle cartelle "x86" e "x64 nella cartella di debug.

La mia applicazione è un'applicazione Web (ASP.NET MVC) e ho dovuto modificare il pool di applicazioni per eseguirlo al LocalSystemposto di ApplicationPoolIdentity. Per fare questo:

1. Apri Gestione IIS
2. Trova il pool di applicazioni in cui è in esecuzione il tuo sito.
3. Fai clic su Impostazioni avanzate dalle azioni
4. Cambia identità in LocalSystem

Non ho idea del perché questo risolva il problema.

Non so se sia una buona risposta, ma sono stato in grado di risolvere questo problema eseguendo la mia applicazione in un AppDomain con un'identità di "Sistema locale".

Sto lavorando a una semplice applicazione console per aggiungere alcuni dati di test a un database SQLite e ho riscontrato questo errore. La configurazione per il progetto è "Qualsiasi CPU". L'ho risolto copiando SQLite.Interop.dll nella cartella bin \ debug. Un modo migliore sarebbe usare il metodo di @Wil, ma come si specifica questo per la configurazione "Any CPU"?

Potrebbe esserci contesa per l'assemblea? Verifica se esiste un'altra applicazione con un blocco file nella DLL.

Se questo è il motivo, dovrebbe essere facile usare uno strumento come Process Explorer di Sysinternal per scoprire il programma offensivo.

HTH, Clay

Per riferimento per chiunque guardi questa domanda:

Se usi il pacchetto nuget, installa una regola di compilazione che esegue la copia per te. (vedi sotto System.Data.SQLite.Core.1.0.94.0 \ build - o qualsiasi versione di Core installata).

Il programma di installazione nuget aggiunge automaticamente la regola al file di progetto.

Questo comunque non risolve il problema del test case. L' approccio DeploymentItem ( https://stackoverflow.com/a/24411049/89584 ) è l'unica cosa che sembra funzionare lì.

Mi sono imbattuto in questo problema, in una soluzione con un progetto Web WebAPI / MVC5 e un progetto di test delle caratteristiche, che hanno entrambi tratto dallo stesso progetto di accesso ai dati (o "Core"). Come molti altri qui, sto usando una copia scaricata tramite NuGet in Visual Studio 2013.

Quello che ho fatto, è stato in Visual Studio aggiunto una cartella della soluzione x86 e x64 al Feature Test e ai progetti Web. Ho quindi fatto un Right Click | Add Existing Item...e ho aggiunto la libreria SQLite.interop.dll appropriata ..\SolutionFolder\packages\System.Data.SQLite.Core.1.0.94.0\build\net451\[appropriate architecture]per ciascuna di quelle cartelle. Poi ho fatto un Right Click | Properties, e ho impostato Copy to Output Directorysu Always Copy. La volta successiva che dovevo eseguire i test delle funzionalità, i test venivano eseguiti correttamente.