System.Data.SQLite von NuGet, Interop-DLL nicht in das Ausgabeverzeichnis kopiert

Question

Ich installierte System.Data.SQLite Core (x86/x64) from NuGet. Es baute ohne Warnungen aber warf System.DllNotFoundException bezüglich SQLite.Interop.dll. Ich habe meine Projekte manipuliert, um die SQLite.Interop.dll aus dem Verzeichnis des NuGet-Pakets in das Ausgabeverzeichnis zu kopieren, und jetzt läuft es ohne die Ausnahme.

Warum hat das NuGet-Paket meine Projekte nicht so konfiguriert, dass die entsprechende Interop-DLL in das Ausgabeverzeichnis geschrieben wird? Es scheint, als ob es dazu in der Lage sein könnte.

Ich bin neu zu interop und ich erbte diese Codebasis, die zuvor System.Data.SQLite.dll direkt durch den Pfad verwiesen. Ich habe zu NuGet gewechselt, um Warnungen über eine Unstimmigkeit zwischen der Prozessorarchitektur des Projekts gegen System.Data.SQLite loszuwerden. Ich versuche alle Projekte als AnyCPU zu erstellen.

Answer 1

Ich dachte, dass dies geschah, als ich die Dateien aus meinem Ausgabeordner an einen anderen Speicherort kopiert habe, wenn ich sie bereitgestellt habe. Ich vermisste die Tatsache, dass die Interop-Dateien kopiert wurden, aber sie werden in x64 und x86-Ordner in Ihrem Ausgabeordner kopiert.

Wenn Sie msbuild im Debug für das Projekt ausführen, können Sie nach Verweisen auf das Ziel CopySQLiteInteropFiles suchen, um sicherzustellen, dass es ausgeführt wird.

Answer 2

In meinem Fall wurde die SQL.Interop.dll nicht von Nuget in irgendeiner Weise kopiert, manuell legte die richtige Version der DLL in den x86 und x64-Ordner das Problem gelöst.

Wenn Sie SQLite von Nuget installiert haben, können Sie die SQL.Interop.dll in diesem Ordner finden (für .NET 4,0)

PROJECT_FOLDER\packages\System.Data.SQLite.Core.1.0.*.*\build\net40

Answer 3

In meinem Fall die myProject.csproj Datei nicht hatte die System.Data.SQLite.Core.targets definiert. Ich fügte die folgende Linie hinzu und beide x64 und x86 Versionen von SQLite.Interop.dll werden jetzt für alle Bauziele kopiert.

<Import Project="..\packages\System.Data.SQLite.Core.1.0.98.1\build\net45\System.Data.SQLite.Core.targets" Condition="Exists('..\packages\System.Data.SQLite.Core.1.0.98.1\build\net45\System.Data.SQLite.Core.targets')" /> 

Ich bin nicht sicher, was passieren wird, wenn das NuGet Paket für System.Data.SQLite.Core aktualisiert wird und wenn der Paketpfad muß manuell geändert werden.

Answer 4

In meinem Fall war das Problem die Tatsache, dass ich SQLite in einem Klassenbibliotheksprojekt verwendete, das dann von einem anderen WPF-Projekt (GUI-Typ) verwendet wurde.

Löste das SQL.Interop.dll nicht auf Ausgabeverzeichnis kopiert zu werden, indem Sie den folgenden Post-Build-Befehl, innerhalb Projekteigenschaften -> Build Event:

xcopy "$(SolutionDir)packages\System.Data.SQLite.Core.1.0.101.0\build\net451\x86\SQLite.Interop.dll" "$(OutputDir)" /y /f 

/y overwrites 
/f displays actual filenames being copied 

Answer 5

in meinem Fall mit NuGet für SQLite Installation und noch muss ich manuell SQliteinterop.dll als Ressource hinzufügen. Dann baue ich muy proyect und wenn ich es veröffentliche, funktioniert es gut. (Arbeiten mit x86-Konfiguration)

Answer 6

Keine der obigen Antworten schien für mich zu arbeiten, vielleicht weil ich auf VS2015 bin, aber das schien mir ein guter Grund, meine eigene Lösung für dieses Problem hinzuzufügen.

Meine spezifische Situation ist die gleiche wie @ Eternal21 - Ich habe eine WPF-Benutzeroberfläche, die eine Client-Bibliothek verbraucht, die SQLite über nuget hinzugefügt hat. Und, ja, das Problem bestand darin, dass die Interop.dll nicht in die Startanwendung kopiert wurde (d. H. In die WPF-Benutzeroberfläche, auf der SQLite nicht installiert ist).

Die Lösung, SQLite einfach mit nuget zum WPF-Projekt hinzuzufügen, ist eine schnelle und einfache Lösung, wenn Sie es eilig haben.

Meine leicht umständliche Lösung verwendet XCOPY, hat aber den Vorteil, dass sie sowohl die x86- als auch die x64-Verzeichnisse kopiert und auch mit Debug- und Release-Builds zurechtkommt. Sein Nachteil ist, dass es fest codierte Projektnamen enthält. Ich kann sehen, wie man ein Makro verwenden kann, um das erste loszuwerden, aber ich konnte nicht leicht sehen, wie man das zweite loswird, also müssten Sie es manuell ändern, wenn sich der Projektname änderte (aber das ist ziemlich selten).

Meine Lösung ist es, diese XCOPY-Befehle in dem Post-Build des Startprojektes zu verwenden:

xcopy $(SolutionDir)DALProject\bin\$(ConfigurationName)\x64\SQLite.Interop.dll $(SolutionDir)WPFProject\bin\$(ConfigurationName)\x64\*.* /C /F /S /E /Y 
xcopy $(SolutionDir)DALProject\bin\$(ConfigurationName)\x86\SQLite.Interop.dll $(SolutionDir)WPFProject\bin\$(ConfigurationName)\x86\*.* /C /F /S /E /Y 

/C - Setzt das Kopieren fort, auch wenn Fehler (vielleicht ist dies nicht erforderlich).

/F - Zeigt die vollständigen Pfade von Dateien an, die kopiert werden (kann zur Bereinigung der Build-Ausgabe weggelassen werden).

/S - Kopiert Unterverzeichnisse (das war der einzige Weg, ich konnte es die Ordner/x86 und/x64 erstellen).

/G - Kopiert Verzeichnisse und Unterverzeichnisse (möglicherweise Duplikate/S).

/Y - Unterdrückt die Eingabeaufforderung, wenn die Zieldatei bereits existiert.

Ich setze dies nur auf den erfolgreichen Build laufen und es funktioniert ein Vergnügen für mich. Hoffe es hilft jemandem.

Answer 7

Mit der System.Data.SQLite.Core NuGet Paket Version 1.0.104 hatte ich das gleiche Problem wie @ Eternal21 und @Patrick. Das heißt, Projekt A referenziert SQLite und Projekt B Referenzen A, wo SQlite.Interop.dll nicht in das Ausgabeverzeichnis von B kopiert wird. Ich habe eine Lösung gefunden, die die Probleme in Projekt A und nicht B löst, was eine robustere Lösung darstellt einmal behebt das Problem für alle zukünftigen Projekte A. beziehe die .targets Datei des NuGet-Paket enthält den folgenden Abschnitt:

<ItemGroup Condition="'$(ContentSQLiteInteropFiles)' != '' And 
         '$(ContentSQLiteInteropFiles)' != 'false' And 
         '@(SQLiteInteropFiles)' != ''"> 
    <Content Include="@(SQLiteInteropFiles)"> 
    <Link>%(RecursiveDir)%(FileName)%(Extension)</Link> 
    <CopyToOutputDirectory>Always</CopyToOutputDirectory> 
    </Content> 
</ItemGroup> 

Dieser Abschnitt fügt SQLite.Interop.dll als Referenz, die A kopiert werden muss die Ausgabe zu projizieren und auch die Ausgabe von Referenzprojekten (wie B). Aber die MSBuild-Eigenschaft ContentSQLiteInteropFiles ist standardmäßig nicht definiert (ich weiß nicht warum), die Referenz durch die erste Bedingung zu deaktivieren. Um sie zu aktivieren, habe ich die folgende Zeile in einem PropertyGroup Element von Projekten .csproj Datei A:

<ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles> 

Bitte beachten Sie, dass diese Linie den Import Element für die .targets Datei des NuGet Paket prececde müssen.

Answer 8

Ich habe ein DLL-Projekt, das das SQLite-Paket von nuget verwendet, aber ein Testprojekt für es würde immer die Ausnahme DLL nicht gefunden auslösen.

Die einfachste Lösung, die ich gefunden habe, war das SQLite nuget-Paket zum Testprojekt hinzuzufügen.

Answer 9

Kopieren Sie diese zu Ihrer Projektdatei:

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

Quelle: SQLite.Interop.dll files does not copy to project output path when required by referenced project