我发现当我允许Nuget更新SQLite到1.0.115.5时，我的项目不再需要'SQLite. interop .dll'。

如果您试图在64位项目中运行32位dll，也可能会出现此错误。

当我在x86和x64文件夹中放置相同的文件(32位版本的SQLite.Interop.dll)时，我得到了这个。

刚刚为我做了这个:在包管理器控制台上安装-Package System.Data.SQLite.Core。

我的应用程序是一个web应用程序(ASP。NET MVC)，我不得不改变应用程序池下运行的LocalSystem而不是ApplicationPoolIdentity。这样做:

打开IIS管理器 找到站点正在运行的应用程序池。 从操作中单击高级设置 将Identity更改为LocalSystem

我不知道为什么这会解决这个问题。

当您处于这种状态时，尝试执行Rebuild-All。如果这解决了问题，您可能会遇到与我相同的问题。

一些背景(我的理解):

SQLite has 1 managed assembly (System.Data.SQLite.dll) and several platform specific assemblies (SQLite.Interop.dll). When installing SQLite with Nuget, Nuget will add the platform specific assemblies to your project (within several folders: \x86, \x64), and configures these dlls to "Copy Always". Upon load, the managed assembly will search for platform specific assemblies inside the \x86 and \x64 folders. You can see more on that here. The exception is this managed assembly attempting to find the relevant (SQLite.Interop.dll) inside these folders (and failing).

我的情况:

我的解决方案中有两个项目;一个WPF应用程序和一个类库。WPF应用程序引用类库，类库引用SQLite(通过Nuget安装)。

对我来说，问题是当我只修改WPF应用程序时，VS试图进行部分重建(意识到依赖的dll没有改变)。在这个过程的某个地方，VS清理了\x86和\x64文件夹的内容(清除了SQLite.Interop.dll)。当我做一个完整的Rebuild-All时，VS正确地复制文件夹及其内容。

我的解决方案:

为了解决这个问题，我添加了一个Post-Build进程，使用xcopy强制将\x86和\x64文件夹从类库复制到我的WPF项目\bin目录。

或者，您可以使用构建配置/输出目录做一些更花哨的事情。

我的情况有点特殊。我在docker容器中运行一个应用程序，并不断得到以下错误

系统。DllNotFoundException:无法加载共享库'SQLite.Interop.dll'或其依赖项之一为了帮助诊断加载问题，可以考虑设置LD_DEBUG环境变量:libSQLite.Interop.dll:不能打开共享目标文件:没有这样的文件或目录

因此，我设置LD_DEBUG=libs，以找出System.Data.SQLite.dll正在查找的文件夹，以查找SQLite.Interop.dll。

你可以在这里找到关于设置LD_DEBUG的信息:http://www.bnikolic.co.uk/blog/linux-ld-debug.html

一旦我这样做了，我意识到SQLite.Interop.dll被找到了。没有找到的DLL是libSQLite.Interop.dll。我应该阅读整个错误消息。

在谷歌上搜索了几个小时后，我找到了这个关于如何从SQLite源代码编译缺失DLL的指南。

注意，实际丢失的文件是libSQLite.Interop.dll.so

编译源代码时，你会得到libsqlite。interop。so，你需要将它重命名为libsqlite。interop。dll。so，然后将它放到它要找的目录中你可以通过设置LD_DEBUG找到它。

对我来说，System.Data.SQLite.dll查找的目录是/usr/lib/x86_64-linux-gnu/