TL; DR;

Question

我定期收到以下异常：

Unable to load DLL 'SQLite.Interop.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

我使用的是1.0.82.0。版本，在VS2010，OS Win7 64中使用nuget进行安装。

一旦异常开始出现，它就会不断出现 - 在VS内部或外部的调试和发布以及运行应用程序。

阻止它的唯一方法是注销和登录。不抛出异常并加载dll。它可以工作几天，但它可以再次破坏。

有没有人见过这样的东西并且有解决方案吗？

Answer 1

我知道我迟到了，但是在我今天推出最新的x86 / x64（版本1.0.88.0）之后我就遇到了这个问题。我在VS2012中的本地IIS默认运行32位，没有简单的方法可以切换到x64。我的生产服务器运行64位。

无论如何我将NuGet包安装到DLL项目中，我收到了这个错误。为了让它正常工作，我必须做的就是将它安装到主站点项目。即使它根本没有触及SQLite类。

我的猜测是SQLite使用条目程序集来检测要加载的Interop版本。

Answer 2

我遇到了这个问题，因为我使用的dll将Sqlite作为依赖项（在NuGet中配置只有Sqlite核心包。）。该项目编译并复制除“SQLite.Interop.dll”（x86和x64文件夹）之外的所有Sqlite dll-s。

解决方案非常简单：只需将Sqlite.Core包作为依赖项（使用NuGet）添加到正在构建/运行的项目中，然后复制dll-s。

Answer 3

在平台目标为Any CPU的WPF项目中使用SQLite时遇到同样的问题。我按照以下步骤修复了它：

在Visual Studio中打开项目设计器。有关如何操作的详细信息，请访问here。
单击“构建”选项卡。
禁用prefer 32-bit选项。

或者，您可以将平台目标设置为x86或x64。我认为这个问题是由System.Data.SQLite库使用平台目标获取'SQLite.Interop.dll'文件的位置引起的。

更新：

如果无法联系到项目设计人员，只需从文本编辑器中打开项目（*.csproj）文件，并将值<Prefer32Bit>false</Prefer32Bit>添加到<PropertyGroup>...</PropertyGroup>标记中。

示例代码

<PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>[Set by Visual Studio]</ProjectGuid>
    <OutputType>Exe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>[Set by Visual Studio]</RootNamespace>
    <AssemblyName>[Set by Visual Studio]</AssemblyName>
    <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
    <FileAlignment>[Set by Visual Studio]</FileAlignment>
    <!--Add the line below to your project file. Leave everything else untouched-->
    <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>

Answer 4

这就是我在项目中修复它的方法。

它正在运行，当一位同事提交了他的更改时，我收到了“无法加载DLL'SQLite.Interop.dll'”例外。

区分项目的.csproj文件，这是非工作版本：

<ItemGroup>
     <Content Include="x64\SQLite.Interop.dll" />
     <Content Include="x86\SQLite.Interop.dll" />
</ItemGroup>

这就是WORKING版本的内容：

<ItemGroup>
     <Content Include="x64\SQLite.Interop.dll">
          <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      </Content>
      <Content Include="x86\SQLite.Interop.dll">
          <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      </Content>
</ItemGroup>

回复后，我没有收到异常。 DLL文件被转储到适当的Debug \ x64（etc）文件夹中。

Answer 5

当您进入此状态时，请尝试执行Rebuild-All。如果这可以解决问题，那么您可能会遇到同样的问题。

一些背景（我的理解）：

SQLite有1个托管程序集（System.Data.SQLite.dll）和几个平台特定程序集（SQLite.Interop.dll）。安装时使用Nuget的SQLite，Nuget将为您的项目添加特定于平台的程序集（在几个文件夹中：\ x86，\ x64），并配置这些 dll“总是复制”。
加载后，托管程序集将搜索平台 \ x86和\ x64文件夹中的特定程序集。你可以看到更多关于那个here。这是一个例外程序集试图在里面找到相关的（SQLite.Interop.dll）这些文件夹（并失败）。

我的情景：

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

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

我的解决方案：

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

或者，你可以使用构建配置/输出目录做更好的事情。

Answer 6

我遇到了运行Visual Studio Express 2013的相同问题。我尝试了这里和其他地方提到的几个解决方案无济于事。我希望这个修复可以帮助其他人。

我在测试基于SQLite的服务的测试类上使用DeploymentItem attribute修复了它。

示例：

[TestClass]
[DeploymentItem(@"x86\SQLite.Interop.dll", "x86")] // this is the key
public class LocalStoreServiceTests
{

    [TestMethod]
    public void SomeTestThatWasFailing_DueToThisVeryIssue()
    {
         // ... test code here
    }
}

这会导致所需的SQLite.Interop.dll被复制到相应的＆＃34; TestResults＆＃34;中的x86目录中。文件夹中。

一切都是绿色的。一切都很好。

Answer 7

从Tools -> Extension and updates更新NuGet并使用命令PM> Update-Package -reinstall System.Data.SQLite.Core重新安装SQLite.Core为我修复了它。

Answer 8

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

就visual studio中的调试而言，一切正常，但部署的版本缺少文件夹x86 /和x64 /包含该DLL。

使用ClickOnce部署之后使其工作的解决方案是在解决方案的启动项目（也是正在发布的项目）中创建这两个子文件夹，将DLL复制到它们中并将它们设置为始终内容复制。

这样，ClickOnce发布工具会自动在清单中包含这些文件和文件夹，并随之部署软件

Answer 9

这里确实有很多答案，但是我的 no-GAC-playing-around 很简单明了。

问题是，可执行文件需要权限SQLite.Interop.dll（x86或x64）的副本才能访问我们的数据库。

大多数架构都有图层，在我的例子中，数据层具有SQLite Connection所需的DLL。

所以我简单地将一个后期构建脚本放入我的数据层解决方案中，一切正常。

TL; DR;

在构建选项中将解决方案的所有项目设置为x86或x64。
使用Post-Build-Script：
将以下SQLite nuget Package添加到项目中
xcopy "$(TargetDir)x64" "$(SolutionDir)bin\Debug\" /y

当然，您必须更改Release Build和x86版本的脚本。

STL; DR;

将SQLite.Interop.dll放在*.exe文件旁边。

Answer 10

因此，在添加NuGet之后，部署不会复制Interops。您可以将它添加到您的csproj文件中，它应该修复该行为：

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

如果您查看Nuite的SQLite源代码，您可以看到它们具体做了些什么。这使我能够使用ASP.Net Core进行部署。

Answer 11

NuGet中SQLite的多架构（x86，x64）版本的默认安装展示了您描述的行为。如果您想为.NET运行时选择在您的计算机上运行应用程序的实际体系结构加载正确的版本，那么您可以为DLL加载程序提供有关在何处找到正确库的提示，如下所示：

在Program.Main（）之前为set32LDirectory（）添加一个kernel32.dll函数调用声明：

    [System.Runtime.InteropServices.DllImport("kernel32.dll", CharSet = System.Runtime.InteropServices.CharSet.Unicode, SetLastError = true)]
    [return: System.Runtime.InteropServices.MarshalAs(System.Runtime.InteropServices.UnmanagedType.Bool)]
    static extern bool SetDllDirectory(string lpPathName);

然后使用您自己的方法确定正确的子目录，以查找“SQLite.Interop.dll”的体系结构特定版本。我使用以下代码：

    [STAThread]
    static void Main()
    {
        int wsize = IntPtr.Size;
        string libdir = (wsize == 4)?"x86":"x64";
        string appPath = System.IO.Path.GetDirectoryName(Application.ExecutablePath);
        SetDllDirectory(System.IO.Path.Combine(appPath, libdir));

Answer 12

旧项目文件格式

即以<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

开头的项目

将以下内容添加到“主” /根项目中的csproj

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

新的SDK项目文件格式

即以<Project Sdk="Microsoft.NET.Sdk.*">

开头的项目

向依赖项链中的每个ProjectReference / PackageImport添加PrivateAssets="none"，直到System.Data.Sqlite PackageImport

例如：

<PackageReference Include="System.Data.SQLite.Core" Version="1.0.110" PrivateAssets="none"/>

Answer 13

即使它是一个旧帖子，我也想分享我在这里找到的解决方案： http://system.data.sqlite.org/index.html/info/54e52d4c6f

如果您不想阅读所有问题，解决方法是将文件“msvcr100.dll”（可以在Windows \ System32目录中找到）复制到与SQLite.Interop.dll相同的路径中。< / p>

我建议阅读问题以了解原因，并将文件包含在您的设置中但仅在发生错误时安装它，我将其设置为可在安装选项中选择的可选组件。

HTH， Formentz

Answer 14

如果SQLite为SQLite.Interop.dll，则根据您的项目构建选项将{{1}}复制到发布或调试文件夹中。

Answer 15

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

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

Answer 16

正如SQLite wiki所说，您的应用程序部署必须是：

所以你需要遵守规则。找到与您的目标平台匹配的dll并将其放置在位置中，如图所示。 Dll可以在YourSolution / packages / System.Data.SQLite.Core。％version％/中找到。

我在应用程序部署方面遇到了问题，所以我刚刚将SQLite.Interop.dll添加到我的项目中，在安装项目中添加了x86文件夹到AppplicationFolder，并添加了对dll的文件引用。

Answer 17

我不知道为什么还没有包括这个，但我必须做研究并为自己找到这个，所以希望有人会找到这个答案并省去麻烦。这是一个WPF应用程序。它在我的开发盒上工作正常，但是在我复制它的计算机上没有工作并得到Unable to load DLL 'SQLite.Interop.dll'错误。当我运行它时，当我得到与OP相同的错误时，我将所有相关的目录和文件直接从我的“Debug”文件夹移植到另一台计算机上。包含我的DLL的我的“bin”文件夹已被复制到“Debug \ bin”，当我使用此路径复制到另一台计算机时，所有文件夹都包含在我的应用程序文件中，因此它没有丢失任何文件。 / p>

我在其他答案中看到的内容不适用：

我没有使用NuGet包，或者需要创建NuGet包创建的x86或x64文件夹。我的DLL（System.Data.SQLite和SQLite.Interop.dll，以及System.Data.SQLite.config）位于我项目的“bin”文件夹中，并手动复制（在解决方案资源管理器中创建“bin”文件夹） VS，在Windows资源管理器中将DLL粘贴到此文件夹中，使用添加＆gt;现有项目将文件放入VS文件夹/项目中。然后我使用该位置在我的项目中将它们引用为Referenced Assemblies（“References”＆gt;“Add Reference”，并浏览到其中一个rinse, repeat）。这可以确保我的项目确切地知道它们的位置。
我不需要在app.config中引用任何SQLite DLL文件，甚至不需要触摸我的MyProject.csproj文件。
我甚至不需要指定特定的处理器！我的项目的构建是针对“任何CPU”，即使我只有混合或64位DLL，并且只能在Windows 7+上运行，这是64位操作系统。（没有x86 /仅32位DLL）
当我遇到OP错误时，我已经将这些DLL指定为“内容”和“复制如果更新”。

我发现的是https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20：

（11）为什么在尝试运行我的应用程序时会出现DllNotFoundException（对于“sqlite3.dll”或“SQLite.Interop.dll”）？

无法找到命名的动态链接库（DLL），或者由于缺少依赖项而无法加载它。确保指定的动态链接库位于应用程序目录或系统路径中的目录中，然后重试。 另外，请确保已安装必要的Visual C ++运行时可再发行组件，除非您使用的是静态链接到它的动态链接库。

强调我在段落内的那个粗体部分。目标计算机是新鲜的，除了.NET 4.0之外没有加载任何程序。一旦我安装了C ++，它就能够完成对SQLite的命令。这应该是最早的常见问题解答之一，也是预备部分的一部分，但它被埋没在＃11。我的开发计算机已经加载了它，因为它附带了Visual Studio，所以这就是它工作的原因。

下载：
Visual Studio 2015的Visual C ++ Redistributable：
https://www.microsoft.com/en-us/download/details.aspx?id=48145

更新3（累积更新）：
https://www.microsoft.com/en-us/download/details.aspx?id=53587

Answer 18

我已经开始使用Costura.Fody打包（.net）程序集并嵌入和预加载本机dll。这也有助于以后分发，因为您可以发送一个文件。

从Nuget安装Costura Fody。
在C＃项目中创建一个名为costrua32的文件夹。在那里添加C＃要加载的任何本机dll。
将它们添加到此文件夹后。单击属性窗口并将构建操作更改为＆＃34;嵌入式资源＆＃34;
最后，您需要修改名为FodyWeavers.xml的XML文件，如下所示。这里我首先指定加载sql dll。（注意你放弃.dll）
```
Weavers
 Costura
  PreloadOrder
   SQLite.Interop
   tbb_debug
   tbb
  /PreloadOrder>
 /Costura
/Weavers
```

这样做的好处是您不必编写任何pre或post构建事件，并且最终产品完全封装在一个更大的文件中。

Answer 19

还（通过Nuget Manager）将dll添加到测试项目中并对其进行了修复。

Answer 20

我很长时间以来一直在努力，偶尔也会发现测试设置不正确。看这个图片： Test setting

我只是取消选中测试设置，问题就消失了。否则，将发生异常。希望，这将有助于某人。不确定它是根本原因。

Answer 21

复制项目目录中的SQLite.Interop.dll。

src\
  project\
      bin\   <-- Past in bin
         x64\
           SQLite.Interop.dll <-- Copy this if 64
         x86\
           SQLite.Interop.dll <-- Copy this if 32

Answer 22

我有同样的问题。请按照以下步骤操作：

确保已安装::ng-deep .pi-chevron-right:before { content: "\e90d"; } ::ng-deep .pi-chevron-down:before { content: "\e90f"; }软件包 {{1}中的System.Data.SQLite.Core。
转到项目解决方案并尝试在SQLite Development Team文件夹中找到NuGet文件夹
检查您的项目框架并选择所需的SQLite.Interop.dll并将其放置在您的debug / release文件夹中

Reference

Answer 23

在构建之前，尝试将平台目标设置为x86或x64（而不是任何CPU）： Project-＆gt; Properties-＆gt; Build-＆gt; Visual Studio中的平台目标。

Answer 24

会不会有集会的争论？检查DLL上是否有另一个带文件锁的应用程序。

如果是这个原因，应该很容易使用像Sysinternal's Process Explorer这样的工具来发现有问题的程序。

HTH，粘土

Answer 25

简而言之

为了使 NCrunch 能够正常工作，我必须将随NuGet包提供的Interop.dll版本添加为additional files in NCrunch configuration。

我的案例

我有一个C＃解决方案，其中一个项目直接依赖于SQLite（一个帮助程序库）和一个使用此帮助程序库的单元测试项目。我已经将System.Data.SQLite.Core版本1.0.97.0安装为NuGet包。

在我的情况下，workaround provided by Marin使它在Visual Studio和CI中也能正常工作。但是，这仍然会在NCrunch中提供错误。

在NCrunch配置中，我在＆＃34;附加文件中添加了以下路径＆＃34;在单元测试项目设置下：

..\packages\System.Data.SQLite.Core.1.0.97.0\build\net45\**.dll

Answer 26

我遇到了这个问题，在一个带有WebAPI / MVC5 Web项目和功能测试项目的解决方案中，它们都采用了相同的数据访问（或“核心”）项目。我和其他许多人一样，正在使用Visual Studio 2013中通过NuGet下载的副本。

我所做的是，在Visual Studio中为功能测试和Web项目添加了x86和x64解决方案文件夹。然后我做了Right Click | Add Existing Item...，并为..\SolutionFolder\packages\System.Data.SQLite.Core.1.0.94.0\build\net451\[appropriate architecture]中的每个文件夹添加了适当的SQLite.interop.dll库。然后，我执行了Right Click | Properties，并将Copy to Output Directory设置为Always Copy。下次我需要运行我的功能测试时，测试成功运行。

Answer 27

我遇到此问题，因为我的PC中没有安装Visual C ++ 2010可再发行组件。如果您尚未安装Visual c + + +可再发行组件Download并安装此项（检查x86或64 dll）。

Answer 28

复制＆＃34; SQLite.Interop.dll＆＃34;调试文件夹中x86和x64的文件。这些文件应该复制到＆＃34; x86＆＃34;和调制文件夹中的＆＃34; x64文件夹。

Answer 29

供查看此问题的人参考：

如果您使用nuget包，它会安装一个构建规则，为您执行复制。（请参阅System.Data.SQLite.Core.1.0.94.0 \ build - 或您安装的任何Core版本。）

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

尽管如此，这仍然无法解决测试用例问题。 DeploymentItem（https://stackoverflow.com/a/24411049/89584）方法是唯一可以在那里工作的方法。

Answer 30

我正在开发一个简单的控制台应用程序，将一些测试数据添加到SQLite数据库中，并收到此错误。该项目的配置是“任何CPU”。我通过将SQLite.Interop.dll复制到bin \ debug文件夹来修复它。更好的方法是使用@Wil的方法，但是如何为“任何CPU”配置指定它？

Answer 31

我不知道这是否是一个好答案，但我能够通过在具有“本地系统”身份的AppDomain下运行我的应用程序来解决此问题。

Answer 32

这对我有用。

在Visual Studio打开的情况下，通过NUGET包管理器搜索并安装SQLite.Core。
转到VS中的解决方案资源管理器，右键单击您的项目名称->添加->新文件夹
命名文件夹x64
重复该过程并添加文件夹并将其命名为x86
右键单击x64文件夹->添加->现有项目，然后浏览到调试文件夹。您会找到x64文件夹。打开它，然后选择“ SQLite.Interop.dll”文件，然后单击“确定”。
对x86文件夹重复步骤5。
右键单击刚添加的DLL，然后选择“属性”。在“复制到输出目录”选项中，选择“始终复制”。
对x64和x86文件夹中的两个DLL重复步骤7。

下次创建项目并转到另一台计算机时，它应该可以正常工作。

Answer 33

您确实需要通过NuGet安装System.Data.SQLite.Core。如果使用InnoSetup，请确保.iss文件的[Files]部分中包含以下行：

Source: "C:\YourProjectPath\bin\Release\x64\*"; DestDir: "{app}\x64"; Flags: ignoreversion recursesubdirs createallsubdirs
Source: "C:\YourProjectPath\bin\Release\x86\*"; DestDir: "{app}\x86"; Flags: ignoreversion recursesubdirs createallsubdirs

为项目路径更改“ YourProjectPath ”。

Answer 34

请为我工作：Install-Package System.Data.SQLite.Core在Package Manager控制台上。

Answer 35

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

System.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 。我应该已经阅读了整个错误消息。

几小时的搜索之后，我发现了这个guide，是关于如何从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/

Answer 36

升级到 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.2.现在只需要等待 AppVeyor 更新他们的 Visual Studio 映像（在此之前可以使用 Previous Visual Studio 2019）。

Answer 37

在SQLLite Core的 Nuget包中，有一个文件 System.Data.SQLite.Core.targets 。只需将此包含在使用此库的所有项目中以及使用库的所有库中。

在您的.csproj或.vbproj文件中添加：每次在bin中编译时，都会在SQLite.Interop.dll文件中添加x86和x64目录。

Answer 38

我的应用程序是一个Web应用程序（ASP.NET MVC），我不得不将应用程序池更改为在LocalSystem而不是ApplicationPoolIdentity下运行。要做到这一点：

打开IIS管理器
找到您的网站正在运行的应用程序池。
点击操作
将身份更改为LocalSystem

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

Answer 39

扩展了Kugel对我有用的答案（VS2015 Enterprise），从构建和测试后的Nuget包中可以删除Nuite包中的SQLite：

1.将Nuget包安装到主项目中。

Install-Package System.Data.SQLite

2.Build应用程序并测试您的Sqlite连接是否正常工作：

select * from sqlite_master

3.从主构建中卸载Nuget包。

UnInstall-Package System.Data.SQLite

4.手动删除SQLite和EntityFramework的dll引用：

System.Data.SQLite
System.Data.SQLite.EF6
System.Data.SQLite.Linq

从主项目的“packages.config”xml文件中删除Xml引用。

这对我有用，让我的项目保持清洁。

Answer 40

Mine也没有用于单元测试，由于某种原因，Michael Bromley的回答涉及DeploymentItem属性不起作用。但是，我使用测试设置工作了。在VS2013中，向解决方案添加新项目并搜索“设置”并选择“测试设置”模板文件。将其命名为“SqliteUnitTests”或其他东西并打开它。选择右侧的“部署”，然后添加目录/文件。将路径/目录添加到SQLite.Interop.dll文件中。对我来说，我添加了两个路径，分别用于Project \ bin \ Debug \ x64和Console \ bin \ Debug \ x86。您可能还想添加Sqlite文件，具体取决于您希望单元测试/解决方案访问该文件的方式。

Answer 41

所以，我的问题是SQLite试图在WPF的设计时加载。由于我只关心x86环境，我将CPU优先级设置为该优先级，并将Nuite包中的SQLite.Interop.dll复制到解决方案的根目录。重新启动解决方案，所有问题都消失了。因此，如果您遇到设计时问题，请将库放入解决方案的根目录中。

此外，我在运行时遇到了类似的问题，因此我不得不将SQLite.Interop.dll的副本放入我的项目中，并将其设置为复制，如果它在属性中较新的话。看来提供的x86和x64文件夹完全没用。需要进一步调查，但总的来说......在项目中手动引用SQLite比使用Nuget包更容易。

此外，官方常见问题解答说明如下：

（20）编译并运行System.Data.SQLite项目时   在Visual Studio中，为什么我会得到一个DllNotFoundException或者   BadImageFormatException（对于＆＃34; sqlite3.dll＆＃34;或者＆＃34; SQLite.Interop.dll＆＃34;）   在尝试运行或调试应用程序时？

从Visual Studio中编译和运行解决方案时   它使用System.Data.SQLite项目（包括测试项目）   选择正确的构建配置非常重要   平台。首先，在Visual中调试托管应用程序   Studio无法使用混合模式组件（即因为它总是如此   编译到特定于平台的构建输出目录）。这是   正确支持为多个平台构建二进制文件所必需的   使用相同的源项目文件。因此，只有   ＆＃34; DebugNativeOnly＆＃34;或＆＃34; ReleaseNativeOnly＆＃34;构建配置应该   从Visual内部运行托管应用程序时选择   依赖于System.Data.SQLite程序集的Studio。这些构建   配置包含复制的自定义后期构建步骤   需要本地程序集到托管输出目录（即到   启用就地运行托管二进制文件）。但是，这个   只有在选定的平台上才会执行构建后步骤   匹配操作系统的（例如＆＃34; Win32＆＃34;用于32位Windows）   和＆＃34; x64＆＃34;对于64位Windows）。因此，这是一个好习惯   根据操作系统仔细检查所选的构建平台   在尝试在解决方案中运行托管项目之前。

https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20

Answer 42

由于此问题的复杂性，我想在此处发布。我的解决方案是回滚到.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文件夹，并单独删除并重新应用。最终删除。

我确实使用.Net 4.0的System.Data.SQLite.Core.1.0.98.0。我打算继续尝试迁移，但我想我会首先开始一个新项目，看看我是否可以让它以这种方式工作。这本来是一个.Net 3.5网络应用程序，在我的旅行中，我发现大量信息仍然引用该框架。

Answer 43

我自己遇到了这个问题，但结果却是另一个原因：

System.DllNotFoundException was caught 
Unable to load DLL 'SQLite.Interop.dll': Access is denied.

在这种情况下，代码是（间接）从IIS托管的Web服务调用的（为x86版本配置）。我最终将它追溯到IIS中的应用程序池：最初我使用的是＆＃34; ASP.NET V4.0集成＆＃34; （导致该错误），但是当我更改它时在＆＃34; DefaultAppPool＆＃34; 之后，问题就消失了。

（唷！）

无法加载DLL'SQLite.Interop.dll'

43 个答案:

TL; DR;

STL; DR;

旧项目文件格式

新的SDK项目文件格式