In regelmäßigen Abständen erhalte ich die folgende Ausnahme:

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

Ich benutze 1.0.82.0. Version, Installation mit Nuget in VS2010, OS Win7 64.

Sobald eine Ausnahme auftritt, wird sie ständig angezeigt - beim Debuggen und Freigeben und Ausführen von Anwendungen innerhalb oder außerhalb von VS.

Die einzige Möglichkeit, dies zu stoppen, ist das Abmelden und Anmelden. Die Ausnahme wird nicht ausgelöst und die DLL wird geladen. Es kann tagelang funktionieren, aber dann kann es wieder brechen.

Hat jemand so etwas gesehen und gibt es eine Lösung dafür?

Ich weiß, dass ich zu spät zur Party komme, aber ich hatte dieses Problem direkt nachdem ich heute das neueste x86 / x64 heruntergezogen hatte (Version 1.0.88.0). Mein lokaler IIS in VS2012 läuft standardmäßig mit 32 Bit und es gibt keine einfache Möglichkeit, zu x64 zu wechseln. Mein Produktionsserver läuft 64bit.

Wie auch immer, ich habe das NuGet-Paket in einem DLL-Projekt installiert und diesen Fehler erhalten. Was ich tun musste, um es zum Laufen zu bringen, musste ich auch im Hauptprojekt installieren . Auch wenn es SQLite-Klassen überhaupt nicht berührt.

Ich vermute, dass SQLite die Eintragsassembly verwendet, um zu ermitteln, welche Version von Interop geladen werden soll.

Ich hatte dieses Problem, weil eine von mir verwendete DLL Sqlite als Abhängigkeit hatte (in NuGet nur mit dem Sqlite-Kernpaket konfiguriert). Das Projekt kompiliert und kopiert alle SQLite-DLLs mit Ausnahme der Datei 'SQLite.Interop.dll' (Ordner x86 und x64).

Die Lösung war sehr einfach: Fügen Sie einfach das Sqlite.Core-Paket als Abhängigkeit (mit NuGet) zu dem Projekt hinzu, das Sie erstellen / ausführen, und die DLLs werden kopiert.

Ich hatte das gleiche Problem bei der Verwendung von SQLite in einem WPF-Projekt, dessen Plattformziel war Any CPU. Ich habe es behoben, indem ich die folgenden Schritte ausgeführt habe:

1. Öffnen Sie den Projektdesigner in Visual Studio. Details dazu finden Sie hier .
2. Klicken Sie auf die Registerkarte Erstellen.
3. Deaktivieren Sie die prefer 32-bitOption.

Alternativ können Sie das Plattformziel auch auf x86oder setzen x64. Ich denke, dieses Problem wird durch die System.Data.SQLiteBibliothek verursacht, die das Plattformziel verwendet, um den Speicherort der Datei 'SQLite.Interop.dll' abzurufen.

AKTUALISIEREN:

Falls der Projektdesigner nicht erreichbar ist, öffnen Sie einfach die project ( *.csproj) - Datei in einem Texteditor und fügen Sie den Wert <Prefer32Bit>false</Prefer32Bit>dem <PropertyGroup>...</PropertyGroup>Tag hinzu.

Beispielcode

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

So habe ich es in meinem Projekt behoben.

Es hat funktioniert, und als ein Kollege seine Änderungen übermittelte, erhielt ich die Ausnahme "DLL 'SQLite.Interop.dll' kann nicht geladen werden".

Anders als in der .csproj-Datei des Projekts war dies in der NON-WORKING-Version:

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

Und das hatte die WORKING-Version:

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

Nach dem Zurückkehren habe ich die Ausnahme nicht erhalten. Die DLL-Dateien wurden in den entsprechenden Debug \ x64 (etc) -Ordnern gespeichert.

Nach dem Hinzufügen von NuGet kopiert die Bereitstellung die Interops nicht. Sie können dies zu Ihrer csproj-Datei hinzufügen und es sollte dieses Verhalten beheben:

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

Wenn Sie in der Quelle nach NuGet for SQLite suchen, können Sie sehen, was diese speziell tun. Dadurch konnte ich eine Bereitstellung mit ASP.Net Core ausführen.

Wenn Sie in diesem Zustand sind, versuchen Sie, ein Rebuild-All durchzuführen. Wenn dies das Problem behebt, haben Sie möglicherweise das gleiche Problem wie ich.

Einige Hintergrundinformationen (mein Verständnis) :

• SQLite verfügt über 1 verwaltete Assembly (System.Data.SQLite.dll) und mehrere plattformspezifische Assemblys (SQLite.Interop.dll). Bei der Installation von SQLite mit Nuget fügt Nuget Ihrem Projekt die plattformspezifischen Assemblys hinzu (in mehreren Ordnern: \ x86, \ x64) und konfiguriert diese DLLs auf "Immer kopieren".

• Beim Laden sucht die verwaltete Assembly nach plattformspezifischen Assemblys in den Ordnern \ x86 und \ x64. Mehr dazu sehen Sie hier . Die Ausnahme ist, dass diese verwaltete Assembly versucht, die relevante (SQLite.Interop.dll) in diesen Ordnern zu finden (und fehlschlägt).

Mein Szenario :

Ich habe 2 Projekte in meiner Lösung; eine WPF-App und eine Klassenbibliothek. Die WPF-App verweist auf die Klassenbibliothek, und die Klassenbibliothek verweist auf SQLite (über Nuget installiert).

Das Problem für mich war, wenn ich nur die WPF-App ändere, VS versucht, eine teilweise Neuerstellung durchzuführen (wobei festgestellt wird, dass sich die abhängige DLL nicht geändert hat). Irgendwo in diesem Prozess bereinigt VS den Inhalt der Ordner \ x86 und \ x64 (SQLite.Interop.dll wird weggeblasen). Wenn ich einen vollständigen Neuaufbau durchführe, kopiert VS die Ordner und ihren Inhalt korrekt.

Meine Lösung :

Um dies zu beheben, habe ich schließlich einen Post-Build-Prozess mit xcopy hinzugefügt, um das Kopieren der Ordner \ x86 und \ x64 aus der Klassenbibliothek in mein WPF-Projektverzeichnis \ bin zu erzwingen.

Alternativ können Sie mit den Build-Konfigurations- / Ausgabeverzeichnissen ausgefallenere Dinge tun.

Ich hatte das gleiche Problem mit Visual Studio Express 2013. Ich habe mehrere hier und anderswo erwähnte Lösungen ohne Erfolg ausprobiert. Ich hoffe, dieses Update hilft anderen.

Ich habe das Problem mithilfe des DeploymentItemAttributs in meiner Testklasse behoben, mit dem der SQLite-basierte Dienst getestet wird.

Beispiel:

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

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

Dies führt dazu SQLite.Interop.dll, dass die erforderlichen x86Daten in das Verzeichnis im entsprechenden Ordner "TestResults" kopiert werden .

Alles ist grün. Alles ist gut.

Das Aktualisieren von NuGet von Tools -> Extension and updatesund das Neuinstallieren von SQLite.Core mit dem Befehl haben PM> Update-Package -reinstall System.Data.SQLite.Corees für mich behoben.

Ich hatte ein ähnliches Problem in einer Lösung mit mehreren Projekten. Die SQLite.Interop.dll war für eines der Plugins erforderlich, die mit ClickOnce mit der Software verteilt wurden.

Beim Debuggen in Visual Studio funktionierte alles einwandfrei, aber in der bereitgestellten Version fehlten die Ordner x86 / und x64 /, die diese DLL enthielten.

Die Lösung, damit es nach der Bereitstellung mit ClickOnce funktioniert, bestand darin, im Startprojekt der Lösung (auch des veröffentlichten) diese beiden Unterordner zu erstellen, die DLLs in sie zu kopieren und sie als Inhaltskopie immer festzulegen.

Auf diese Weise nimmt das ClickOnce-Veröffentlichungstool diese Dateien und Ordner automatisch in das Manifest auf und stellt die Software mit ihnen bereit

Hier gibt es wirklich viele Antworten, aber meine ist einfach und klar, da kein GAC herumgespielt wird .

Das Problem war, dass die ausführbare Datei eine Kopie des Rechts SQLite.Interop.dll(x86 oder x64) benötigt, um auf unsere Datenbank zugreifen zu können.

Meistens haben Architekturen Schichten, und in meinem Fall verfügt die Datenschicht über die erforderliche DLL für SQLite Connection.

Also habe ich einfach ein Post-Build-Skript in meine Datenschichtlösung eingefügt und alles hat gut funktioniert.

TL; DR;

1. Stellen Sie alle Projekte Ihrer Lösung auf x86oder x64in den Erstellungsoptionen ein.

2. Fügen Sie Post-Build-Scriptdem Projekt Folgendes hinzu mit SQLite nuget Package:

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

Natürlich müssen Sie das Skript für Release Buildund x86Builds ändern .

STL; DR;

Stellen Sie Ihre SQLite.Interop.dllneben die *.exeDatei.

Die Standardinstallation der SQLite-Version mit mehreren Architekturen (x86, x64) von NuGet weist das von Ihnen beschriebene Verhalten auf. Wenn Sie die richtige Version für die tatsächliche Architektur laden möchten, die die .NET-Laufzeit zum Ausführen Ihrer Anwendung auf Ihrem Computer ausgewählt hat, können Sie dem DLL-Loader wie folgt einen Hinweis geben, wo sich die richtige Bibliothek befindet:

Fügen Sie vor Ihrem Program.Main () eine Deklaration für den Funktionsaufruf kernel32.dll zu SetDLLDirectory () hinzu:

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

Verwenden Sie dann Ihre eigene Methode, um das richtige Unterverzeichnis zu ermitteln und die architekturspezifische Version von 'SQLite.Interop.dll' zu finden. Ich benutze den folgenden Code:

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

Auch wenn es sich um einen alten Beitrag handelt, möchte ich die Lösung, die ich hier gefunden habe, weitergeben: http://system.data.sqlite.org/index.html/info/54e52d4c6f

Wenn Sie nicht das gesamte Problem lesen möchten, besteht die Lösung darin, die Datei "msvcr100.dll" (die sich im Verzeichnis Windows \ System32 befindet) in denselben Pfad wie SQLite.Interop.dll zu kopieren.

Ich würde empfehlen, das Problem zu lesen, um zu verstehen, warum und um die Datei in Ihr Setup aufzunehmen. Um sie jedoch nur zu installieren, wenn der Fehler auftritt, habe ich sie zu einer optionalen Komponente gemacht, die in den Setup-Optionen ausgewählt werden kann.

HTH, Formentz

Wie im SQLite-Wiki angegeben , muss Ihre Anwendungsbereitstellung wie folgt sein:

Sie müssen also die Regeln befolgen. Finden Sie eine DLL, die zu Ihrer Zielplattform passt, und platzieren Sie sie an einem Ort, wie im Bild beschrieben. DLLs finden Sie in YourSolution / packages / System.Data.SQLite.Core.% Version% /.

Ich hatte Probleme mit der Anwendungsbereitstellung, daher habe ich meinem Projekt die richtige SQLite.Interop.dll hinzugefügt, den App86-Ordner im Setup-Projekt um den x86-Ordner erweitert und Dateiverweise zur DLL hinzugefügt.

Sie können diesen Fehler auch erhalten, wenn Sie versuchen, eine 32-Bit-DLL in einem 64-Bit-Projekt auszuführen.

Ich habe dies erhalten, wenn ich dieselbe Datei (SQLite.Interop.dll in 32-Bit-Version) sowohl im x86- als auch im x64-Ordner abgelegt habe.

Wenn Sie die richtige Binärdatei für herunterladen,SQLite kopieren SQLite.Interop.dllSie sie entsprechend Ihrer Projekterstellungsoption in Ihren Release- oder Debug- Ordner.

Ich weiß nicht, warum dies noch nicht aufgenommen wurde, aber ich musste die Nachforschungen anstellen und es selbst herausfinden, also wird hoffentlich jemand diese Antwort finden und die Mühe sparen. Dies war für eine WPF-App. Es funktionierte gut auf meiner Dev-Box, aber nicht auf dem Computer, auf dem ich es kopierte und den Unable to load DLL 'SQLite.Interop.dll'Fehler bekam . Ich habe alle zugehörigen Verzeichnisse und Dateien direkt von meinem "Debug" -Ordner auf diesen anderen Computer portiert, als ich den gleichen Fehler wie das OP beim Ausführen bekam. Mein "bin" -Ordner, der meine DLLs enthielt, wurde nach "Debug \ bin" kopiert und alle wurden zusammen mit meinen Anwendungsdateien eingeschlossen, als ich über diesen Pfad auf den anderen Computer kopierte, sodass keine Dateien fehlten.

Dinge, die ich in anderen Antworten gesehen habe, die nicht zutrafen:

• Ich habe das NuGet-Paket nicht verwendet oder musste x86- oder x64-Ordner erstellen, die anscheinend vom NuGet-Paket erstellt wurden. Meine DLLs (System.Data.SQLite und SQLite.Interop.dll sowie System.Data.SQLite.config) befinden sich in meinem Projekt im Ordner "bin" und wurden manuell kopiert (Ordner "bin" im Projektmappen-Explorer in erstellen VS, fügen Sie DLLs in diesen Ordner im Windows Explorer ein und verwenden Sie Hinzufügen> Vorhandenes Element, um Dateien in den VS-Ordner / das VS-Projekt zu bringen. Dann verweise ich sie in meinem Projekt an diesem Speicherort als referenzierte Baugruppen ("Referenzen"> "Referenz hinzufügen" und navigiere zu einer, spüle, wiederhole sie für den Rest). Dies stellt sicher, dass mein Projekt genau weiß, wo sie sich befinden.
• Ich musste keine SQLite-DLL-Datei in meiner app.config referenzieren oder sogar meine MyProject.csproj-Datei berühren.
• Ich musste nicht einmal einen bestimmten Prozessor angeben! Der Build meines Projekts ist für "Beliebige CPU" vorgesehen, obwohl ich nur gemischte oder 64-Bit-DLLs habe und nur unter Windows 7+ ausgeführt werde, bei denen es sich um 64-Bit-Betriebssysteme handelt. (keine reinen x86 / 32-Bit-DLLs)
• Ich habe sie bereits als "Inhalt" und "Kopie, wenn neuer" für diese DLLs angegeben, als der OP-Fehler auftrat.

Was ich gefunden habe, war Folgendes von https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20 :

(11) Warum erhalte ich eine DllNotFoundException (für "sqlite3.dll" oder "SQLite.Interop.dll"), wenn ich versuche, meine Anwendung auszuführen?

Entweder kann die benannte DLL (Dynamic Link Library) nicht gefunden werden oder sie kann aufgrund fehlender Abhängigkeiten nicht geladen werden. Stellen Sie sicher, dass sich die benannte dynamische Linkbibliothek im Anwendungsverzeichnis oder in einem Verzeichnis entlang des Systempfads befindet, und versuchen Sie es erneut. Stellen Sie außerdem sicher, dass die erforderliche weiterverteilbare Visual C ++ - Laufzeit installiert wurde, es sei denn, Sie verwenden eine dynamische Verknüpfungsbibliothek, die statisch mit dieser verknüpft wurde.

Betonen Sie meine auf diesen fettgedruckten Teil innerhalb des Absatzes. Der Zielcomputer war frisch und hatte keine Programme außer .NET 4.0 geladen. Nachdem ich C ++ installiert hatte, konnte es die Befehle für SQLite ausführen. Dies hätte eine der ersten FAQs und Teil der Voraussetzungen sein sollen, wurde aber auf Platz 11 begraben. Mein Entwicklungscomputer hatte es bereits geladen, weil es mit Visual Studio geliefert wurde. Deshalb hat es dort funktioniert.

Download:
Visual C ++ Redistributable für Visual Studio 2015:
https://www.microsoft.com/en-us/download/details.aspx?id=48145

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

Ich habe begonnen, Costura.Fody zu verwenden, um Assemblys (.net) zu verpacken und native DLLs einzubetten und vorzuladen. Dies hilft auch später bei der Verteilung, da Sie eine Datei senden können.

1. Installieren Sie Costura Fody von Nuget.

2. Erstellen Sie in Ihrem C # -Projekt einen Ordner mit dem Namen costrua32. Fügen Sie dort alle nativen DLLs hinzu, die Sie mit C # laden möchten.

3. Sobald Sie sie diesem Ordner hinzugefügt haben. Klicken Sie auf das Eigenschaftenfenster und ändern Sie die Build-Aktion in "Eingebettete Ressource".

4. Schließlich müssen Sie die XML-Datei mit dem Namen FodyWeavers.xml wie folgt ändern. Hier gebe ich an, zuerst die SQL-DLL zu laden. (Beachten Sie, dass Sie die DLL löschen)

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

Dies hat den Vorteil, dass Sie keine Ereignisse vor oder nach dem Build schreiben müssen und das Endprodukt vollständig in eine größere Datei eingekapselt ist.

Außerdem wurde die DLL zum Testprojekt hinzugefügt (über Nuget Manager) und behoben.

Ich hatte dieses Problem, weil Visual C ++ 2010 Redistributable nicht auf meinem PC installiert war. Wenn Sie Visual C ++ 2010 Redistributable noch nicht installiert haben, laden Sie es herunter und installieren Sie es (überprüfen Sie die x86- oder 64-DLL).

Ich habe das gleiche Problem. Endlich kann ich es jedoch beheben. Derzeit verwende ich Visual Studio 2013 Community Edition. Ich verwende einfach Add-> Existing Item ... und navigiere zu den SQLite.Data.SQLite-Dateien (mein Fall ist 'C: \ Programme (x86) \ System.Data.SQLite \ 2013 \ bin'). Bitte vergessen Sie nicht, den Typ Ihrer Aufnahme in Assembly-Dateien (* .dll; * .pdb) zu ändern . Wählen Sie in diesem Ordner ' SQLite.Interop.dll '. Von dort und dann kann ich ohne Probleme weitermachen. Viel glück, euch allen. ^ _ ^ PS Ich erstelle eine Webformularanwendung. Ich habe es noch nicht in Windows Form Application oder anderen versucht.

Versuchen Sie, das Plattformziel vor dem Erstellen auf x86 oder x64 (und nicht auf eine beliebige CPU) festzulegen: Projekt-> Eigenschaften-> Erstellen-> Plattformziel in Visual Studio.

Kopieren Sie SQLite.Interop.dll in das Projektverzeichnis.

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

Ich habe lange damit zu kämpfen gehabt und gelegentlich festgestellt, dass die Testeinstellung falsch ist. Siehe dieses Bild:

Ich deaktiviere einfach die Testeinstellung und das Problem verschwindet. Andernfalls tritt die Ausnahme auf. Hoffentlich hilft das jemandem. Ich bin mir nicht sicher, ob es die Grundursache ist.

Kopieren Sie die Dateien "SQLite.Interop.dll" für x86 und x64 in den Debug-Ordner. Diese Dateien sollten in die Ordner "x86" und "x64" im Debug-Ordner kopiert werden.

Meine Anwendung ist eine Webanwendung (ASP.NET MVC) und ich musste den Anwendungspool ändern, unter dem ausgeführt LocalSystemwerden soll ApplicationPoolIdentity. Um dies zu tun:

1. Öffnen Sie den IIS-Manager
2. Suchen Sie den Anwendungspool, unter dem Ihre Site ausgeführt wird.
3. Klicken Sie in den Aktionen auf Erweiterte Einstellungen
4. Ändern Sie die Identität in LocalSystem

Ich habe keine Ahnung, warum dies das Problem behebt.

Ich weiß nicht, ob es eine gute Antwort ist, aber ich konnte dieses Problem lösen, indem ich meine Anwendung unter einer AppDomain mit der Identität "Lokales System" ausführte.

Ich arbeite an einer einfachen Konsolenanwendung, um einer SQLite-Datenbank einige Testdaten hinzuzufügen, und habe diesen Fehler erhalten. Die Konfiguration für das Projekt lautet "Beliebige CPU". Ich habe es behoben, indem ich die Datei SQLite.Interop.dll in den Ordner bin \ debug kopiert habe. Ein besserer Weg wäre, die Methode von @Wil zu verwenden, aber wie geben Sie dies für die Konfiguration "Beliebige CPU" an?

Könnte es Streit um die Versammlung geben? Überprüfen Sie, ob die DLL eine andere Anwendung mit einer Dateisperre enthält.

Wenn dies der Grund ist, sollte es einfach sein, ein Tool wie den Process Explorer von Sysinternal zu verwenden, um das fehlerhafte Programm zu ermitteln.

HTH, Clay

Als Referenz für alle, die sich diese Frage ansehen:

Wenn Sie das Nuget-Paket verwenden, wird eine Build-Regel installiert, die das Kopieren für Sie übernimmt. (Siehe unter System.Data.SQLite.Core.1.0.94.0 \ build - oder welche Version von Core Sie auch installieren).

Das Nuget-Installationsprogramm fügt die Regel automatisch Ihrer Projektdatei hinzu.

Dies behebt das Testfallproblem jedoch immer noch nicht. Der DeploymentItem- Ansatz ( https://stackoverflow.com/a/24411049/89584 ) ist das einzige, was dort zu funktionieren scheint.

Ich bin auf dieses Problem in einer Lösung mit einem WebAPI / MVC5-Webprojekt und einem Feature-Test-Projekt gestoßen, die beide aus demselben Datenzugriffsprojekt (oder 'Kern'-Projekt) stammten. Ich verwende, wie so viele andere hier, eine Kopie, die über NuGet in Visual Studio 2013 heruntergeladen wurde.

In Visual Studio wurde dem Funktionstest und den Webprojekten ein x86- und x64-Lösungsordner hinzugefügt. Ich habe dann eine erstellt Right Click | Add Existing Item...und die entsprechende SQLite.interop.dll-Bibliothek ..\SolutionFolder\packages\System.Data.SQLite.Core.1.0.94.0\build\net451\[appropriate architecture]für jeden dieser Ordner hinzugefügt . Ich habe dann ein Right Click | Properties, und Satz Copy to Output Directoryzu Always Copy. Wenn ich das nächste Mal meine Funktionstests ausführen musste, wurden die Tests erfolgreich ausgeführt.