Datei oder Assembly 'System.Data.SQLite' konnte nicht geladen werden.

126

Ich habe ELMAH 1.1 .Net 3.5 x64 in meinem ASP.NET-Projekt installiert und erhalte jetzt die folgende Fehlermeldung (wenn ich versuche, eine Seite anzuzeigen):

Datei oder Assembly 'System.Data.SQLite, Version = 1.0.61.0, Culture = neutral, PublicKeyToken = db937bc2d44ff139' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Es wurde versucht, ein Programm mit einem falschen Format zu laden.

Beschreibung: Während der Ausführung der aktuellen Webanforderung ist eine nicht behandelte Ausnahme aufgetreten. Bitte überprüfen Sie die Stapelverfolgung, um weitere Informationen über den Fehler und dessen Ursprung im Code zu erhalten.

Ausnahmedetails: System.BadImageFormatException: Datei oder Assembly 'System.Data.SQLite, Version = 1.0.61.0, Culture = neutral, PublicKeyToken = db937bc2d44ff139' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Es wurde versucht, ein Programm mit einem falschen Format zu laden.

Weitere Fehlerdetails unten.

Meine Active Solution-Plattform ist "Beliebige CPU" und ich verwende ein x64-Windows 7 auf einem x64-Prozessor. Der Grund, warum wir diese Version von ELMAH verwenden, ist, dass 1.0 .Net 3.5 (x86, die einzige Plattform, für die es kompiliert wurde) auf unserem x64-Windows-Server denselben Fehler verursachte.

Ich habe versucht, für x86 und x64 zu kompilieren, und ich erhalte den gleichen Fehler. Ich habe versucht, die gesamte Compiler-Ausgabe (bin und obj) zu entfernen. Schließlich habe ich direkt auf die SQLite-DLL verwiesen, was nicht erforderlich war, damit das Projekt auf dem Server funktioniert, und ich habe diesen Compilerfehler:

Fehler 1 Warnung als Fehler: Assemblygenerierung - Die referenzierte Assembly 'System.Data.SQLite.dll' zielt auf ein anderes Prozessor-MyProject ab

Irgendwelche Ideen, was das Problem sein könnte?

Weitere Fehlerdetails:

Quellfehler:

Während der Ausführung der aktuellen Webanforderung wurde eine nicht behandelte Ausnahme generiert. Informationen zum Ursprung und Ort der Ausnahme können mithilfe der folgenden Ausnahmestapelverfolgung identifiziert werden.

Stapelverfolgung:

[BadImageFormatException: Datei oder Assembly 'System.Data.SQLite, Version = 1.0.61.0, Culture = neutral, PublicKeyToken = db937bc2d44ff139' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Es wurde versucht, ein Programm mit einem falschen Format zu laden.]
System.Reflection.Assembly._nLoad (AssemblyName Dateiname, String codeBase, Evidence AssemblySecurity, Assembly locationHint, StackCrawlMark & ​​stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) +0
System.Reflection. .nLoad (AssemblyName Dateiname, String codeBase, Evidence AssemblySecurity, Assembly locationHint, StackCrawlMark & ​​stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) +43
System.Reflection.Assembly.InternalLoad (AssemblyName AssemblyRef, Evidence AssemblySecurity, StackCrawlMark & ​​StackMark, Boolean forIntrospection) Laden (String AssemblyString) +28
System.Web.Configuration.CompilationSection.LoadAssemblyHelper (String AssemblyName, Boolean starDirective) +46

[ConfigurationErrorsException: Datei oder Assembly 'System.Data.SQLite, Version = 1.0.61.0, Culture = neutral, PublicKeyToken = db937bc2d44ff139' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Es wurde versucht, ein Programm mit einem falschen Format zu laden.]
System.Web.Configuration.CompilationSection.LoadAssemblyHelper (Zeichenfolge AssemblyName, Boolean starDirective) +613 System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory () +203 SystemWfiguration .CompilationSection.LoadAssembly (AssemblyInfo ai) +105
System.Web.Compilation.BuildManager.GetReferencedAssemblies (CompilationSection compConfig) +178
System.Web.Compilation.BuildProvidersCompiler..ctor (VirtualPath configPath, BooleanAusgabeLokalUserUnterAnleitung)
System.Web.Compilation.ApplicationBuildProvider.GetGlobalAsaxBuildResult (Boolean isPrecompiledApp) +232
System.Web.Compilation.BuildManager.CompileGlobalAsax () +52 System.Web.Compilation.BuildManager.En

[HttpException (0x80004005): Datei oder Assembly 'System.Data.SQLite, Version = 1.0.61.0, Culture = neutral, PublicKeyToken = db937bc2d44ff139' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Es wurde versucht, ein Programm mit einem falschen Format zu laden.]
System.Web.Compilation.BuildManager.ReportTopLevelCompilationException () +58 System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled () +512 System.Web.Hosting.HostingEnvironment. ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters HostingParameters) +729

[HttpException (0x80004005): Datei oder Assembly 'System.Data.SQLite, Version = 1.0.61.0, Culture = neutral, PublicKeyToken = db937bc2d44ff139' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Es wurde versucht, ein Programm mit einem falschen Format zu laden.]
System.Web.HttpRuntime.FirstRequestInit (HttpContext-Kontext) +8896783
System.Web.HttpRuntime.EnsureFirstRequestInit (HttpContext-Kontext) +85
System.Web.HttpRuntime.Proquest ) +259

pupeno
quelle
Ein Fusion-Protokoll (Assembly Binding) ist in solchen Fällen viel nützlicher als dieses Blatt einer Stapelverfolgung.
Anton Tykhyy
1
Es scheint, dass das Problem war, dass Cassini x86 ist.
Pupeno
Ich hatte das gleiche Problem und musste ELMAH wegen der gemischten Produktions- / Entwicklungsumgebung, die wir haben, aufgeben. Angesichts der Tatsache, dass die Verwendung von SQLite auf einem Webserver für die Produktion mit hohem Datenverkehr nicht sehr gut klingt und die SQLite-DLL die einzige Assembly in ELMAH ist, die zwei verschiedene Versionen für x86- und 64x-Bit erzwingt, frage ich mich, warum ELMAH-Leute ziehen es heraus und machen es optional, anstatt was es jetzt ist.
Khash

Antworten:

122

System.Data.SQLite.dllist eine gemischte Assembly, dh sie enthält sowohl verwalteten Code als auch nativen Code. Daher ist ein bestimmtes System.Data.SQLite.dllentweder x86 oder x64, aber niemals beides.

Update (mit freundlicher Genehmigung von J. Pablo Fernandez ): Cassini, der von Visual Studio verwendete Entwicklungswebserver, wenn Sie F5 drücken oder auf die grüne Schaltfläche "Wiedergabe" klicken, ist nur x86, was bedeutet, dass Sie es auch sind, wenn Ihre Workstation x64 ist kann die x86-Version von System.Data.SQLite.dll verwenden.

Eine Alternative besteht darin, nicht Cassini zu verwenden, sondern IIS7, das ordnungsgemäß x64 ist.

Anton Tykhyy
quelle
3
Ich verwende die x64-Version auf einem x64-Computer.
Pupeno
Haben Sie versucht, die x86-Version zu verwenden?
Anton Tykhyy
2
Eine neue Alternative, die vor kurzem verfügbar wurde, ist die Verwendung von IIS Express, mit dem Sie den Typ des Anwendungspools festlegen können, den Sie verwenden möchten
Raul Vejar
@ Raul Vejar: Bitte erläutern Sie, wie die Funktion zur Auswahl des Anwendungspools von IIS Express das 32-Bit / 64-Bit-Assemblyproblem löst. Vielen Dank
Tim
@Tim, mit dieser Funktion können Sie den Typ des Anwendungspools auswählen, den Sie verwenden möchten, entweder 32- oder 64-Bit. Auf diese Weise können Sie den in Cassini festgelegten Aspekt steuern und mit derselben Bitbibliothek arbeiten, die Sie haben. Mit anderen Worten, wenn Sie die 32-Bit-Version der SQLite-DLL verwenden, sollten Sie den 32-Bit-Anwendungspool in IIS Express auswählen. Für die 64-Bit-Version der Bibliothek sollten Sie den 64-Bit-Anwendungspool auswählen.
Raul Vejar
77

Stellen Sie sicher, dass "32-Bit-Anwendungen aktivieren" für den App-Pool auf "false" gesetzt ist.

beckelmw
quelle
2
Dies funktioniert, wenn Sie die x86-DLL auf einem 64-Bit-Computer verwenden möchten. In unserem Fall stimmen unsere Entwicklungs- und Produktionsumgebungen nicht überein, daher funktionierte dies am besten.
Rob
17
Wenn ich es für mich auf true setze, ist das Problem tatsächlich gelöst. Ich denke, Elmah wird standardmäßig mit der 32-Bit-SQL-Lite-Assembly ausgeliefert.
1
+1 für @Jirapong und Sergey, weil ich diese Einstellung manipulieren musste, um die Dinge zum Laufen zu bringen. In meinem Fall hatte ich die x86-Version der SqlLite-DLL und musste 32-Bit-Anwendungen aktivieren auf "true" setzen.
t3rse
43

Gehe zum IIS7 Application Pool -> advanced settings and set the 32-bit application to true.

umar
quelle
Ich verwende Windows 7 und bin auf dieses Problem gestoßen. Das Einschalten von 32-Bit hat es für mich behoben, vermutlich weil meine Kopie der DLL 32-Bit war.
Doug
1
Zu Ihrer Information: Es war erforderlich, die Identität des Anwendungspools auf LocalSystem zu setzen, damit dies funktioniert: ^
Illuminati
Und stellen Sie sicher, dass Sie eine Win32-Version von SQLite.Interop.dll stackoverflow.com/questions/4816529/…
Morten Holmgaard
14

Dies ist sehr einfach, wenn Sie SQLite nicht verwenden:

Sie können die SQLite-DLLs aus den Bin-Ordnern Ihrer Lösung und dann aus dem Ordner löschen, in dem Sie auf ELMAH verweisen. Wird neu erstellt und Ihre App versucht nicht, diese DLL zu laden, die Sie nicht verwenden.

Chris
quelle
5
+1 Wenn Sie SQLite nicht verwenden, warum sollten Sie dann die referenzierte DLL reparieren? Schön, elegant und genau das, was ich brauchte.
Bhavinb
Dies funktionierte lokal, aber nach der Bereitstellung in Azure wurde der Fehler angezeigt.
stuartdotnet
8

Ich habe eine 64-Bit-Entwicklungsmaschine und einen 32-Bit-Build-Server. Ich habe diesen Code vor der NHibernate-Initialisierung verwendet. Wirkt auf jede Architektur (sowohl die 2, die ich getestet habe)

Hoffe das hilft jemandem.

Guido

        private static void LoadSQLLiteAssembly()
        {
            Uri dir = new Uri(Assembly.GetExecutingAssembly().CodeBase);
            FileInfo fi = new FileInfo(dir.AbsolutePath);           
            string binFile = fi.Directory.FullName + "\\System.Data.SQLite.DLL";
            if (!File.Exists(binFile)) File.Copy(GetAppropriateSQLLiteAssembly(), binFile, false);
        }

        private static string GetAppropriateSQLLiteAssembly()
        {
            string pa = Environment.GetEnvironmentVariable("PROCESSOR_ARCHITECTURE");
            string arch = ((String.IsNullOrEmpty(pa) || String.Compare(pa, 0, "x86", 0, 3, true) == 0) ? "32" : "64");
            return GetLibsDir() + "\\NUnit\\System.Data.SQLite.x" + arch + ".DLL";
        }
Gatapia
quelle
Hat jemand diese Technik erfolgreich angewendet? Ich habe es in einer Test-Asp.net-MVC-App-Lösung versucht und es hat bei mir nicht funktioniert.
Glenn
1
Anstatt zur Umgebungsvariablen zu wechseln, können Sie die CLR direkt verwenden: string arch = IntPtr.Size == 8? "x64": "x86";
Jason Morse
2
Oder die Environment.Is64BitProcess- Eigenschaft (seit .NET4).
Riezebosch
5

In unserem Fall hat es nicht funktioniert, weil unser Produktionsserver fehlt

Weiterverteilbares Microsoft Visual C ++ 2010 SP1-Paket (x86)

Wir haben es installiert und alles funktioniert gut. Für den Anwendungspool muss "32-Bit-Anwendungen aktivieren" auf "true" gesetzt sein, und Sie müssen die x86-Version der Bibliothek verwenden

Marcos Meli
quelle
1
Funktioniert bei mir. Es wird nur eine Fehlermeldung ausgegeben, ohne darauf hinzuweisen, dass die C-Bibliothek fehlt, was schrecklich ist.
Brk
1
Für mich habe ich vcredist 2008 x64 für System.Data.SQLite installiert, Version = 1.0.99.0, Culture = neutral, PublicKeyToken = db937bc2d44ff139
themadmax
5

Als jemand, der sich mit einigen Fehlerberichten im Roadkill-Wiki mit genau demselben Problem befassen musste, müssen Sie Folgendes tun:

  • Verwenden Sie x64 oder x86? Sqlite wird mit DLLs für separate Architekturen geliefert. Kopieren Sie die richtige in Ihren Bin-Ordner. Für den offiziellen Anbieter gibt es zwei DLLs:System.Data.SQLite.dll System.Data.SQLite.Linq.dll
  • Wenn Sie sich nicht die Mühe machen müssen, nach diesen Assemblys zu suchen, aktivieren Sie den 32-Bit-Modus für Ihren App-Pool (eine Lösung normalerweise nur für Entwicklungsmaschinen).
  • Wenn Sie auf einem Server hosten, muss Microsoft C ++ Runtime weiterverteilbar sein - es ist standardmäßig nicht auf Server 2008 R2 installiert. x64-Version , x86-Version

Es ist ein echtes Ärgernis, durch wie viele Rahmen Sie springen müssen, wenn Sie die SQLite .NET-Binärdateien neu verteilen. Meine Lösung für Roadkill bestand letztendlich darin, die richtigen Binärdateien basierend auf der von Ihnen verwendeten Architektur in den Ordner ~ / bin zu kopieren . Leider löst das das C ++ - Laufzeitproblem nicht.

Chris S.
quelle
5

Ich habe dieses Problem behoben, indem ich System.Data.SQLite mit der Erweiterung Nuget installiert habe. Diese Erweiterung kann für Visual Studio 2010 oder höher verwendet werden. Zuerst müssen Sie die Nuget-Erweiterung installieren. Sie können hier folgen:

  • Gehen Sie zu Visual Studio 2010, Menü -> Extras
  • Wählen Sie Extension Manager
  • Geben Sie NuGet in das Suchfeld ein und klicken Sie auf Online-Galerie. Warten darauf Informationen abrufen…
  • Wählen Sie den abgerufenen NuGet Package Manager aus und klicken Sie auf Herunterladen. Warten auf Download…
  • Klicken Sie im Visual Studio Extension Installer NuGet Package Manager auf Installieren. Warten Sie, bis die Installation abgeschlossen ist.
  • Klicken Sie auf Schließen und jetzt neu starten.

Zweitens können Sie jetzt SQLite installieren:

Und jetzt können Sie System.Data.SQLite verwenden.

In diesem Fall sehen Sie zwei Ordner x64 und x86. Diese Ordner enthalten SQLite.Interop.dll. Gehen Sie nun zu den Eigenschaftenfenstern dieser DLLs und legen Sie fest, dass die Build-Aktion Inhalt ist und "In Ausgabeverzeichnis kopieren" immer "Kopieren" ist.

Das ist also mein Weg.

Vielen Dank. Kim Tho Pham, HoChiMinh Stadt, Vietnam. E-Mail: [email protected]

Kim Thọ Phạm
quelle
4

Die manuelle lastbezogene System.Data.SQLite-Assembly kann dies beheben.

Der Code von gatapia wurde wie folgt geändert:

    public static void LoadSQLLiteAssembly()
    {
        Uri dir = new Uri(Assembly.GetExecutingAssembly().CodeBase);
        FileInfo fi = new FileInfo(dir.AbsolutePath);
        string appropriateFile = Path.Combine(fi.Directory.FullName, GetAppropriateSQLLiteAssembly());
        Assembly.LoadFrom(appropriateFile);
    }

    private static string GetAppropriateSQLLiteAssembly()
    {
        string pa = Environment.GetEnvironmentVariable("PROCESSOR_ARCHITECTURE");
        string arch = ((String.IsNullOrEmpty(pa) || String.Compare(pa, 0, "x86", 0, 3, true) == 0) ? "32" : "64");
        return "System.Data.SQLite.x" + arch + ".DLL";
    }
lxwwqw
quelle
4

Ich habe diesen Fehler erhalten, als unser Windows-Server von 32-Bit-Betriebssystem auf 64-Bit konvertiert wurde. Die Assembly, die den Fehler ausgelöst hat, wurde so eingestellt, dass sie im x86-Modus (dh im 32-Modus) kompiliert wird. Ich habe es auf "Any CPU" umgestellt und das hat den Trick gemacht. Sie können diesen Wert folgendermaßen ändern:

Klicken Sie mit der rechten Maustaste auf das Projekt und gehen Sie zu Properties -> Build -> Platform Target -> change to "Any CPU"

goku_da_master
quelle
1
Ich habe versucht, 32-Bit-System.Data.SQLite.dll zu verwenden und diese Ausnahme beim Ausführen auf 64-Bit-CPU zu erhalten. Ich habe das Plattformziel von "Beliebige CPU" in "x86" geändert und die Ausnahme wurde dadurch behoben. Ich denke, wenn Sie nicht versuchen, die Leistung zu maximieren, ist es besser, für den kleinsten gemeinsamen Nenner zu bauen, damit er entweder auf einer 32- oder 64-Bit-CPU läuft.
cdavidyoung
3

Seltsamerweise habe ich dies behoben, indem ich System.Data.SQLite über die Nuget-GUI-Anwendung im Gegensatz zur Paketmanagerkonsole installiert habe.

Die Installation über die Konsole enthielt nicht die Abhängigkeiten, die diese Bibliothek ausführen muss.

JMK
quelle
3

System.Data.SQLitehängt davon ab System.Data.SQLite.interop, ob beide Pakete dieselbe Version und beide x86 sind .

Dies ist eine alte Frage, aber ich habe alles versucht. Ich habe an einem ausschließlich x86- Projekt gearbeitet, daher gab es nicht zwei Ordner / x86, / x64. Aber aus irgendeinem Grund war das System.Data.SQLiteeine andere Version als System.Data.SQLite.interop, nachdem ich passende DLLs heruntergezogen hatte, wurde das Problem behoben.

Staplerfluss
quelle
1

Ich habe 2 schnelle Lösungen gefunden. Entweder für mich arbeiten. Ich denke, das Problem liegt an den Berechtigungen.

1) Anstatt die Datei Elmah.dll aus dem Verzeichnis net-2.0 zu verwenden, habe ich Elmah.dll aus net-1.1 verwendet.

2) Anstatt Elmah.dll im Projekt-Bin-Verzeichnis zu belassen. Ich mache ein DLL-Verzeichnis, um es abzulegen.

Anon
quelle
1

Eine andere Möglichkeit, dies zu umgehen, besteht darin, Ihre Anwendung auf ELMAH 1.2 anstatt auf 1.1 zu aktualisieren.

Peter Bernier
quelle
0

Können Sie Ihren bin-Debug-Ordner löschen und erneut kompilieren?

Oder überprüfen Sie Ihren Projektverweis auf System.Data.SQLite, finden Sie heraus, wo er sich befindet, und öffnen Sie dann die DLL im Reflektor. Wenn Sie es nicht öffnen können, bedeutet dies, dass die DLL beschädigt ist. Möglicherweise möchten Sie eine korrekte finden oder das .net-Framework neu installieren.

Graviton
quelle
Ich habe versucht, den Verweis direkt auf System.Data.SQLite hinzuzufügen (abgesehen vom Entfernen von bin und obj), und ich habe folgende Fehlermeldung erhalten: Fehler 1 Warnung als Fehler: Assemblygenerierung - Referenzierte Assembly 'System.Data.SQLite.dll 'zielt auf einen anderen Prozessor MyProject
pupeno
0

Wenn Sie IIS Express als Webserver auf Ihrem Entwicklungscomputer verwenden, würde ich zu Local IIS wechseln. Das hat bei mir funktioniert.

cyclo_magic
quelle
0

Dies ist ein alter Beitrag, aber es kann einigen Personen, die nach diesem Fehler suchen, helfen, "32-Bit-Anwendungen aktivieren" für den App-Pool auf "Wahr" zu setzen. Das hat den Fehler für mich behoben. Ich bin auf diese Lösung gestoßen, indem ich einige Kommentare zu @ beckelmws Antwort gelesen habe.

MichaelD
quelle
0

Sie haben wahrscheinlich das falsche Paket installiert. Sie möchten das von Microsoft erstellte Paket, das das System.Data.Common-Anbietermodell implementiert.

Zuhälter
quelle