定期我得到以下异常:
无法加载DLL 'SQLite.Interop.dll':无法找到指定的模块。(异常来自HRESULT: 0x8007007E)
我使用的是1.0.82.0。在VS2010, Win7 64操作系统下使用nuget安装。
一旦异常开始出现，它就会不断出现——在调试和发布中，在VS内部或外部运行应用程序。
阻止它的唯一方法就是退出并重新登录。不抛出异常并加载dll。 它可以工作几天，但之后又会坏掉。
有人见过这样的情况吗，有解决方案吗?
当前回答
所以，我的问题是SQLite试图在WPF的设计时加载。由于我只关心x86环境，所以我将CPU首选项设置为x86环境，并将Nuget包中的SQLite.Interop.dll复制到解决方案的根目录。重新启动解决方案，所有问题都消失了。因此，如果遇到设计时问题，请将库放到解决方案的根目录中。
此外，我在运行时遇到了类似的问题，所以我必须将SQLite.Interop.dll的副本放入我的项目中，并将其设置为复制，如果它在属性中较新的。似乎x86和x64提供的文件夹是完全无用的。还需要进一步的调查，但总的来说…在你的项目中手动引用SQLite比使用Nuget包更容易。
此外，官方常见问题解答如下:
(20) When the System.Data.SQLite project is compiled and run from inside Visual Studio, why do I get a DllNotFoundException or a BadImageFormatException (for "sqlite3.dll" or "SQLite.Interop.dll") when trying to run or debug the application? When compiling and running a solution from within Visual Studio that uses the System.Data.SQLite project (including the test project), it is very important to select the correct build configuration and platform. First, managed applications to be debugged inside Visual Studio cannot use the mixed-mode assembly (i.e. because it is always compiled to the platform-specific build output directory). This is necessary to properly support building binaries for multiple platforms using the same source project files. Therefore, only the "DebugNativeOnly" or "ReleaseNativeOnly" build configurations should be selected when running a managed application from inside Visual Studio that relies upon the System.Data.SQLite assembly. These build configurations contain a custom post-build step that copies the required native assembly to the managed output directory (i.e. to enable running the managed binaries in-place). However, this post-build step will only be performed if the selected platform matches that of the operating system (e.g. "Win32" for 32-bit Windows and "x64" for 64-bit Windows). Therefore, it is good practice to double-check the selected build platform against the operating system prior to attempting to run a managed project in the solution.
https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20
其他回答
如果您试图在64位项目中运行32位dll，也可能会出现此错误。
当我在x86和x64文件夹中放置相同的文件(32位版本的SQLite.Interop.dll)时，我得到了这个。
大会上会有竞争吗?检查DLL上是否有其他具有文件锁的应用程序。
如果是这个原因，使用Sysinternal的Process Explorer之类的工具来发现有问题的程序应该很容易。
HTH, 粘土
因此，在添加了NuGet之后，部署不会复制Interops。你可以把这个添加到你的csproj文件中，它应该会修复这个行为:
<PropertyGroup>
<ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles>
<CopySQLiteInteropFiles>false</CopySQLiteInteropFiles>
<CleanSQLiteInteropFiles>false</CleanSQLiteInteropFiles>
<CollectSQLiteInteropFiles>false</CollectSQLiteInteropFiles>
</PropertyGroup>
如果你看一下NuGet for SQLite的源代码，你可以看到这些具体在做什么。这允许我使用ASP进行部署。净的核心。
在SQLLite Core的Nuget包中有一个文件System.Data.SQLite.Core.targets。只需将此包含在使用此库的所有项目和使用您库的所有库中。
在你的.csproj或.vbproj文件中添加: 每次你在你的bin中编译都会添加x86和x64目录下的SQLite.Interop.dll文件。
刚刚为我做了这个:在包管理器控制台上安装-Package System.Data.SQLite.Core。
