大会上会有竞争吗?检查DLL上是否有其他具有文件锁的应用程序。

如果这是原因，使用Sysinternal的进程资源管理器这样的工具来发现违规程序应该很容易。

我在WPF项目中使用SQLite时遇到了同样的问题，该项目的平台目标是Any CPU。我通过以下步骤修复了它:

1. 在Visual Studio中打开项目设计器。如何做到这一点的详细信息可以在在这里中找到。
2. 单击Build选项卡。
3. 禁用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>

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

来自NuGet的多体系结构(x86, x64)版本SQLite的默认安装显示了您所描述的行为。如果你想加载。net运行时选择在你的机器上运行你的应用程序的实际体系结构的正确版本，那么你可以给DLL加载器一个关于在哪里找到正确库的提示，如下所示:

在Program.Main()之前添加kernel32.dll函数调用SetDLLDirectory()的声明:

    [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));

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

无论如何，我安装了NuGet包到一个DLL项目，我得到了这个错误。我要做的是让它工作，我也必须将其安装到主站点项目。即使它根本不涉及SQLite类。

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

这是我在我的项目中解决它的方法。

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

区别项目的.csproj文件，这是在NON-WORKING版本中:

<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)文件夹中。

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

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

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

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

如果您不想读取所有问题，解决方案是将“msvcr100.dll”文件(可以在Windows\System32目录中找到)复制到与SQLite.Interop.dll相同的路径。

我建议阅读问题以了解原因，并在安装程序中包含该文件，但仅在错误发生时才安装它，我在安装程序选项中使其成为可选组件。

如果你为SQLite 下载正确的二进制，那么根据你的项目构建选项将SQLite.Interop.dll复制到你的释放或调试文件夹中。

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

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

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

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

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

一些背景知识(我的理解):

• SQLite有一个托管程序集(System.Data.SQLite.dll)和几个 平台特定的程序集(SQLite.Interop.dll)。在安装 SQLite与Nuget, Nuget将添加平台特定的程序集到您的项目 (在几个文件夹中:\x86， \x64)，并配置这些

加载时，托管程序集将搜索平台 \x86和\x64文件夹中的特定程序集。你可以看到 更多关于在这里。唯一的例外是这个被管理 程序集试图在其中找到相关的(SQLite.Interop.dll)
.
.

我的场景:

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

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

我的解决方案:

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

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

我在运行Visual Studio Express 2013时也遇到了同样的问题。我尝试了这里和其他地方提到的几种解决方案，但都没有用。我希望这个修正能帮助到其他人。

我通过在测试基于sqlite的服务的测试类上使用DeploymentItem属性来修复它。

例子:

[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被复制到适当的“TestResults”文件夹中的x86目录。

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

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

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

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

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

我有这个问题，因为我正在使用的dll有Sqlite作为依赖项(在NuGet中配置只有Sqlite核心包)。该项目编译并复制除' Sqlite . interop .dll' (x86和x64文件夹)之外的所有Sqlite dll。

解决方案非常简单:只需将System.Data.SQLite.Core包作为依赖项(使用NuGet)添加到您正在构建/运行的项目中，dll就会被复制。

我有这个问题，因为Visual c++ 2010可重分发没有安装在我的电脑。如果你还没有安装Visual c++ 2010 redistributable 下载并安装这个(检查x86或64 dll)。

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

1. 从Nuget安装Costura Fody。

2. 在c#项目中创建一个名为costrua32的文件夹。在那里添加任何本地dll你要加载c#。

3. 一旦您将它们添加到此文件夹。单击属性窗口，将构建操作更改为“嵌入式资源”

4. 最后，您需要修改名为fody韦弗斯. XML的XML文件，如下所示。这里我指定首先加载sql dll。(请注意您删除了.dll)

   Weavers
   Costura
   PreloadOrder
   SQLite.Interop
   tbb_debug
   tbb
   /PreloadOrder>
   /Costura
   /Weavers
   

The advantage of this is that you do not have to write any pre or post build events, and the end product is totally encapsulated in to one larger file.

我在一个WebAPI/MVC5 web项目和一个特性测试项目的解决方案中遇到了这个问题，这两个项目都来自同一个数据访问(或“核心”)项目。像这里的许多人一样，我使用的是通过NuGet在Visual Studio 2013中下载的副本。

我所做的，是在Visual Studio中添加一个x86和x64解决方案文件夹到功能测试和Web项目中。然后我做了一个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。下一次我需要运行特性测试时，测试成功地运行了。

简而言之

为了让它也能与NCrunch一起工作，我必须添加NuGet包提供的Interop.dll版本作为NCrunch配置中的附加文件。

我的情况

我有一个c#解决方案，其中一个项目直接依赖于SQLite(一个帮助库)和一个使用这个帮助库的单元测试项目。我已经安装了System.Data.SQLite.Core版本1.0.97.0作为NuGet包。

在我的情况下，Marin提供的解决方案让它在Visual Studio和CI中工作。然而，这仍然会在NCrunch中提供错误。

在NCrunch配置中，我在单元测试项目设置下的“附加文件”中添加了以下路径:

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

我自己也遇到过这个问题，但事实证明是另一个原因:

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

在这种情况下，代码是从IIS托管的web服务(为x86版本配置)中(间接地)调用的。我最终在IIS中的应用程序池中找到了它:最初我使用的是“ASP。NET V4.0集成”(这导致了这个错误)，但当我将其更改为“DefaultAppPool”时，问题就消失了。

(唷!)

因为这个问题的复杂性，我想在这里发表。我的解决方案是回滚到。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应用程序，在我的旅行中，我发现大量的信息仍然引用了这个框架。

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

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

此外，官方常见问题解答如下:

(20)当System.Data.SQLite项目被编译并从 在Visual Studio中，为什么我得到一个DllNotFoundException或者 BadImageFormatException(用于“sqlite3.dll”或“sqlite3. interop .dll”) 在尝试运行或调试应用程序时?< / p > 当在Visual Studio中编译和运行解决方案时 使用System.Data.SQLite项目(包括测试项目)，它 选择正确的构建配置和 平台。首先，在Visual中调试托管应用程序 工作室不能使用混合模式组装(即，因为它总是 编译到特定于平台的构建输出目录)。这是 必须正确地支持为多个平台构建二进制文件 使用相同的源项目文件。因此，只有 "DebugNativeOnly"或"ReleaseNativeOnly"构建配置应该 在Visual中运行托管应用程序时选择 依赖于System.Data.SQLite程序集的Studio。这些构建 配置包含一个自定义的构建后步骤，该步骤将复制 所需的本机程序集到托管输出目录(即 启用就地运行托管二进制文件)。然而,这 仅当选择平台时，才执行构建后步骤 与操作系统匹配(例如:Win32: 32位Windows操作系统 和“x64”(64位Windows)。因此，这是很好的练习 根据操作系统仔细检查所选的构建平台 在尝试在解决方案中运行托管项目之前

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

我的也不能用于单元测试，而且出于某种原因，Michael Bromley涉及deploymenttem属性的答案也不能工作。但是，我使用测试设置让它工作。在VS2013中，添加一个新项目到你的解决方案中，搜索“settings”并选择“Test settings”模板文件。命名为SqliteUnitTests之类的然后打开它。选择右边的“部署”，并添加目录/文件。向SQLite.Interop.dll文件添加路径/目录。对我来说，我添加了两条路径，分别用于Project\bin\Debug\x64和Console\bin\Debug\x86。您可能还想添加Sqlite文件，这取决于您希望单元测试/解决方案如何访问该文件。

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

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

问题是，可执行文件需要一个正确的SQLite.Interop.dll (x86或x64)的副本来访问我们的数据库。

大多数架构都有层，在我的情况下，数据层具有SQLite连接所需的DLL。

所以我简单地把一个后构建脚本到我的数据层解决方案和一切工作正常。

TL,博士;

1. 在构建选项中将解决方案的所有项目设置为x86或x64。

2. 用SQLite nuget Package将下面的Post-Build-Script添加到项目中:

   xcopy "$(TargetDir)x64" "$(SolutionDir)bin\Debug\" /y

当然，你必须为Release Build和x86版本更改脚本。

STL,博士;

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

复制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

扩展Kugel的回答，这对我来说是有效的(VS2015 Enterprise)，利用dll中的SQLite，可以在构建和测试后从主项目中删除Nuget包:

1.安装Nuget包到主项目。

Install-Package System.Data.SQLite

2.构建应用程序并测试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

5. 从主项目的“包”中删除Xml引用。配置”XML文件。

   李< / p > < / >

这对我来说很有效，使我的项目保持干净。

将x86和x64的“SQLite.Interop.dll”文件复制到调试文件夹中。这些文件应该复制到调试文件夹中的“x86”和“x64”文件夹中。

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

我在其他答案中看到的不适用的东西:

• 我没有使用NuGet包或需要创建x86或x64文件夹，似乎是NuGet包创建的。My dll (System.Data. dll)SQLite和SQLite. interop .dll，以及System.Data.SQLite.config)在我的项目中的“bin”文件夹中，并手动复制(在VS中的解决方案资源管理器中创建“bin”文件夹，将dll粘贴到Windows资源管理器中的此文件夹中，使用Add > Existing Item将文件带入VS文件夹/项目)。然后我引用它们作为引用程序集在我的项目中使用该位置(“引用”>“添加引用”，并浏览到一个，冲洗,重复其余)。这确保我的项目知道它们的确切位置。
• 我不需要在我的app.config中引用任何SQLite DLL文件，甚至触摸我的MyProject。csproj文件。
• 我甚至不需要指定特定的处理器!我的项目的构建是“任何CPU”，即使我只有混合或64位dll，将只运行在Windows 7+，这是64位操作系统。(没有x86-only/32- only dll)
• 当我遇到OP的错误时，我已经为这些dll指定了“Content”和“copy if newer”。

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

(11)为什么我得到一个DllNotFoundException(“sqlite3.dll”或“SQLite.Interop.dll”)当试图运行我的应用程序? < br > < br > 无法定位命名动态链接库(DLL)，或者由于缺少依赖项而无法加载它。请确保命名的动态链接库位于应用程序目录或系统PATH沿线的目录中，然后重试。另外，确保已经安装了必要的Visual c++运行时可重分发文件，除非你使用的是静态链接到它的动态链接库

我要强调这段内粗体的部分。目标计算机是新的，除了. net 4.0之外没有加载任何程序。一旦我安装了c++，它就能够完成SQLite的命令。这应该是第一个常见问题之一，也是先决条件的一部分，但它被埋在了第11位。我的开发计算机已经加载了它，因为它带有Visual Studio，所以这就是它在那里工作的原因。

< p > 下载: < br > Visual c++ Redistributable for Visual Studio 2015:
https://www.microsoft.com/en-us/download/details.aspx?id=48145 < / p >

更新3(累积更新):
https://www.microsoft.com/en-us/download/details.aspx?id=53587 < / p >

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

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

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

正如SQLite维基所说，你的应用程序部署必须是:

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

我有应用程序部署的问题，所以我只是添加了正确的SQLite.Interop.dll到我的项目中，在安装项目中添加了x86文件夹到applicicationfolder，并添加了文件引用到dll。

因此，在添加了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。只需将此包含在使用此库的所有项目和使用您库的所有库中。

还添加了dll到测试项目(通过Nuget管理器)，它修复了它。

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

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

因此，我设置LD_DEBUG =填词来找出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/

刚刚为我工作了:包管理器控制台上的Install-Package System.Data.SQLite.Core。

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'。

旧项目文件格式

即以<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.*">开头的项目

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

例:

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

这对我来说很管用。

1. 打开Visual Studio，搜索并安装SQLite。核心通过NUGET包管理器。
2. 在VS中的解决方案资源管理器中，右键单击你的项目名称—>ADD—>新建文件夹
3. 将文件夹命名为x64
4. 重复上述过程，并添加文件夹并将其命名为x86
5. 右键单击x64文件夹——>ADD——>EXISTING ITEM，然后浏览到DEBUG文件夹。您将找到x64文件夹。打开它，选择“SQLite.Interop.dll"文件，然后点击确定。
6. x86文件夹重复步骤5。
7. 右键单击刚才添加的DLL并选择PROPERTIES。在“复制到输出目录”选项中，选择始终复制。
8. 对x64和x86文件夹中的dll重复步骤7。

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

我也有同样的问题。请遵循以下步骤:

1. 确保你已经安装了System.Data.SQLite.Core包通过 SQLite Development Team from NuGet.
2. 转到项目解决方案并尝试在packages文件夹中找到build文件夹
3. 检查您的项目框架并选择所需的SQLite.Interop.dll并将其放置在调试/发布文件夹中

Reference .

升级到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图像(直到那时可以使用Previous 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"

我尝试了几乎所有的解决方案，但没有任何运气。最终解决这个问题的方法是将我选择的平台对应的SQLite.Interop.dll的副本直接放在我的安装项目的根目录下。

我不知道为什么它起作用了，但它确实起了作用。

超过30个答案，但我用了不同的方法。

我有两个独立的项目。一个Windows服务，和一个Windows窗体应用程序。应用程序引用WS项目，两者都引用SQLite核心nuget包。

在构建WS项目时，有x64和x32文件夹。但在构建应用程序时，文件夹不会显示出来。

检查这里的答案，我不能让他们工作。但是我发现WS项目中有以下代码片段，而App项目中没有。我添加了它，现在文件夹显示正确。

<Import Project="..\packages\System.Data.SQLite.Core.1.0.112.0\build\net46\System.Data.SQLite.Core.targets" Condition="Exists('..\packages\System.Data.SQLite.Core.1.0.112.0\build\net46\System.Data.SQLite.Core.targets')" />

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

我想到了一个解决办法。

在我的情况下，我使用微软Visual Studio安装程序项目。 安装项目不会从主要输出中看到x64和x86文件夹和内容

解决方案:

1. 将x64和x86文件夹都添加到安装程序中的应用程序文件夹中。
2. 添加两个文件夹的内容。

这将允许安装程序复制SQLite工作所需的DLL文件。