定期我得到以下异常:

无法加载DLL 'SQLite.Interop.dll':无法找到指定的模块。(异常来自HRESULT: 0x8007007E)

我使用的是1.0.82.0。在VS2010, Win7 64操作系统下使用nuget安装。

一旦异常开始出现,它就会不断出现——在调试和发布中,在VS内部或外部运行应用程序。

阻止它的唯一方法就是退出并重新登录。不抛出异常并加载dll。 它可以工作几天,但之后又会坏掉。

有人见过这样的情况吗,有解决方案吗?


当前回答

升级到Visual Studio 2019版。16.10导致了我的问题,其中msbuild报告了以下System.Data.SQLite.Core-package:

CopySQLiteInteropFiles:
Skipping target "CopySQLiteInteropFiles" because it has no outputs.

https://github.com/dotnet/msbuild/issues/6493

微软表示,该漏洞已被修复。16.10.4. 现在只需要等待AppVeyor更新他们的Visual Studio图像(在此之前,可以使用以前的Visual Studio 2019)。

现在,AppVeyor正在为当前和以前的Visual Studio 2019-image使用破碎的dotnet-build-engine。现在一个必须显式安装dotnet sdk ver。5.0.302:

Invoke-WebRequest -Uri 'https://dot.net/v1/dotnet-install.ps1' -UseBasicParsing -OutFile "$env:temp/dotnet-install.ps1"; & $env:temp\dotnet-install.ps1 -Architecture x64 -Version 5.0.302 -InstallDir "$env:ProgramFiles\dotnet"

其他回答

对于任何关注这个问题的人来说:

如果您使用nuget包,它会安装一个构建规则,为您执行复制。(参见System.Data.SQLite.Core.1.0.94.0\build -或任何你安装的Core版本)。

nuget安装程序会自动将规则添加到项目文件中。

但是,这仍然不能解决测试用例问题。deploymenttem (https://stackoverflow.com/a/24411049/89584)方法似乎是惟一可行的方法。

因为这个问题的复杂性,我想在这里发表。我的解决方案是回滚到。net 4.0。我已经测试了3天了,还不能让System.Data.SQLite.Core.1.0.98.0与. net 4.5或. net 4.5.1一起工作。

测试在3台计算机、2台服务器和一台开发PC上进行。我还没能找到问题的根源。我已经尝试编辑.vsproj文件。我已经将SQLite.interop.dll添加到所有文件夹中。我已经将包应用到所有GAC文件夹,并单独删除和重新应用。最终删除。

我有System.Data.SQLite.Core.1.0.98.0与。net 4.0一起工作。我打算继续尝试迁移,但我想我会先开始一个新项目,看看我是否能让它以那种方式工作。它最初是一个。net 3.5 web应用程序,在我的旅行中,我发现大量的信息仍然引用了这个框架。

我知道我来晚了,但在我今天下载了最新的x86/x64(版本1.0.88.0)后,我就遇到了这个问题。我在VS2012中的本地IIS默认运行32位,没有简单的方法切换到x64。我的生产服务器运行64位。

无论如何,我安装了NuGet包到一个DLL项目,我得到了这个错误。为了让它工作,我必须把它安装到主站点项目中。即使它根本不涉及SQLite类。

我的猜测是SQLite使用入口程序集来检测要加载哪个版本的Interop。

当您处于这种状态时,尝试执行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目录。

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

我在多个项目的解决方案中遇到了类似的问题。SQLite.Interop.dll对于使用ClickOnce随软件发布的一个插件是必要的。

在visual studio中调试一切正常,但是部署的版本缺少包含DLL的文件夹x86/和x64/。

使用ClickOnce让它在部署后工作的解决方案是在解决方案的启动项目(也是正在发布的项目)中创建这两个子文件夹,将dll复制到其中,并将它们设置为Content copy Always。

通过这种方式,ClickOnce发布工具自动将这些文件和文件夹包含在清单中,并使用它们部署软件