无法加载DLL的SQLite.Interop.dll。

Periodically I am getting the following exception:

我定期得到以下例外情况:

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

无法加载DLL的SQLite.Interop。dll:无法找到指定的模块。(从HRESULT例外:0 x8007007e)

I am using 1.0.82.0. version, installing it with nuget in VS2010, OS Win7 64.

我用1.0.82.0。版本，在VS2010中安装nuget, OS Win7 64。

Once exception starts to appear, it appears constantly - in debug and release and running application within or outside VS.

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

The only way to stop it is logoff and logon. The exception is not thrown and dll is loaded. It can work for days, but then it can break again.

唯一能阻止它的方法是下线和登录。不抛出异常，加载dll。它可以工作好几天，但之后它又可以休息了。

Has anyone seen something like this and is there a solution for it?

有人见过这样的东西吗?有解决办法吗?

36 个解决方案

#1

I know I'm late to the party but I had this issue right after I pulled down latest x86/x64 today (version 1.0.88.0). My local IIS in VS2012 runs 32bit by default and there's no easy way to switch to x64. My production server runs 64bit.

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

Anyway I installed the NuGet package to a DLL project and I got this error. What I had to do to get it working I had to install it to the main site project, too. Even if it doesn't touch SQLite classes at all.

无论如何，我把NuGet包安装到一个DLL项目中，我得到了这个错误。我必须要做的是把它安装到主站点项目中。即使它根本不接触SQLite类。

My guess is that SQLite uses the entry assembly to detect which version of Interop to load.

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

#2

I had this problem because a dll I was using had Sqlite as a dependency (configured in NuGet with only the Sqlite core package.). The project compiles and copies all the Sqlite dll-s except the 'SQLite.Interop.dll' (both x86 and x64 folder).

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

The solution was very simple: just add the Sqlite.Core package as a dependency (with NuGet) to the project you are building/running and the dll-s will be copied.

解决方案非常简单:只需添加Sqlite。核心包作为一个依赖项(包含NuGet)到您正在构建/运行的项目，而dlls将被复制。

#3

I had this same problem when using SQLite in a WPF project whose platform target was Any CPU. I fixed it by following the following steps:

我在WPF项目中使用SQLite时遇到了同样的问题，它的平台目标是任何CPU。我通过以下步骤解决了这个问题:

1. Open the project designer in Visual Studio. Details on how to do it can be found here.
2. 在Visual Studio中打开项目设计器。关于如何做的细节可以在这里找到。
3. Click on the Build tab.
4. 单击Build选项卡。
5. Disable the prefer 32-bit option.
6. 禁用偏好32位的选项。

Alternatively, you could just set the platform target to x86 or x64. I think this problem is caused by the System.Data.SQLite library using the platform target to get the location of the 'SQLite.Interop.dll' file.

或者，您可以将平台目标设置为x86或x64。我认为这个问题是由系统造成的。使用平台目标来获取SQLite.Interop的位置。dll文件。

UPDATE:

更新:

In case the project designer cannot be reached, just open the project (*.csproj) file from a text editor and add the value <Prefer32Bit>false</Prefer32Bit> into the <PropertyGroup>...</PropertyGroup> tag.

如果无法到达项目设计器，只需从文本编辑器中打开项目(*.csproj)文件，并将值 false 放入 …< / PropertyGroup >标记。

Example code

示例代码

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

#4

This is how I fixed it in my project.

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

It was working, and when a colleague submitted his changes, I received the "Unable to load DLL 'SQLite.Interop.dll'" exception.

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

Diffing the project's .csproj file, this was in the NON-WORKING version:

在项目的.csproj文件中，这是在非工作版本中:

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

And this is what the WORKING version had:

这就是工作版本的内容:

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

After reverting back, I didn't receive the exception. The DLL files were dumped in the appropriate Debug\x64 (etc) folders.

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

#5

When you get in this state, try performing a Rebuild-All. If this fixes the problem, you may have the same issue I had.

当您进入这个状态时，试着执行一个重新构建—all。如果这解决了问题，您可能会遇到与我相同的问题。

Some background (my understanding):

一些背景(我的理解):

• 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".

  SQLite有1个托管程序集(System.Data.SQLite.dll)和几个平台特定程序集(SQLite.Interop.dll)。在使用Nuget安装SQLite时，Nuget会将平台特定的程序集添加到您的项目中(在几个文件夹中:\x86， \x64)，并配置这些dll以“永远复制”。

• 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).

  在加载时，托管程序集将在\x86和\x64文件夹中搜索特定于平台的程序集。你可以在这里看到更多。异常是这个托管程序集试图在这些文件夹中找到相关的(SQLite.Interop.dll)(以及失败)。

My Scenario:

我的情况:

I have 2 projects in my solution; a WPF app, and a class library. The WPF app references the class library, and the class library references SQLite (installed via Nuget).

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

The issue for me was when I modify only the WPF app, VS attempts to do a partial rebuild (realizing that the dependent dll hasn't changed). Somewhere in this process, VS cleans the content of the \x86 and \x64 folders (blowing away SQLite.Interop.dll). When I do a full Rebuild-All, VS copies the folders and their contents correctly.

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

My Solution:

我的解决方案:

To fix this, I ended up adding a Post-Build process using xcopy to force copying the \x86 and \x64 folders from the class library to my WPF project \bin directory.

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

Alternatively, you could do fancier things with the build configuration / output directories.

或者，您可以使用构建配置/输出目录来做更高级的事情。

#6

I had the same issue running Visual Studio Express 2013. I tried several solutions mentioned here and elsewhere to no avail. I hope this fix helps others.

我在2013年的Visual Studio Express上也有同样的问题。我在这里和其他地方尝试了几种解决方案，但都无济于事。我希望这个补丁能帮助别人。

I fixed it by using the DeploymentItem attribute on my test class that tests the SQLite-based service.

我在测试类中使用deploymenttem属性来测试基于sqliteservice的服务。

Example:

例子:

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

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

This causes the needed SQLite.Interop.dll to get copied to the x86 directory within the appropriate "TestResults" folder.

这导致了需要的SQLite.Interop。在适当的“TestResults”文件夹中，dll被复制到x86目录。

All is green. All is good.

都是绿色的。都是好的。

#7

Updating NuGet from Tools -> Extension and updates and reinstalling SQLite.Core with the command PM> Update-Package -reinstall System.Data.SQLite.Core fixed it for me.

更新NuGet从工具->扩展和更新和重新安装SQLite。核心与命令PM> Update-Package -reinstall System.Data.SQLite。Core为我解决了这个问题。

#8

There are really a lot of answers here, but mine is simple and clear with no-GAC-playing-around.

这里确实有很多答案，但我的答案很简单，也很清楚，不需要玩游戏。

The problem was, the executable File needs a copy of the right SQLite.Interop.dll (x86 or x64) to access our Database.

问题是，可执行文件需要一个右SQLite.Interop的拷贝。dll (x86或x64)访问我们的数据库。

Mostly architectures have layers and in my case the Data Layer has the required DLL for SQLite Connection.

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

So i simple put a post build script into my Data Layer Solution and everything worked fine.

所以我简单地将一个post构建脚本放到我的数据层解决方案中，一切都很好。

---

TL;DR;

1. Set all Projects of your solution to x86 or x64 in the build options.
2. 在构建选项中设置您的解决方案的所有项目到x86或x64。

3. Add following Post-Build-Script to the Project with the SQLite nuget Package:

   使用SQLite nuget包向项目添加以下后构建脚本:

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

   选择复制文件“(TargetDir)x64“美元”(SolutionDir)本\调试\“美元/ y

Of course you have to change the script for Release Build and x86 builds.

当然，您必须修改版本构建和x86构建的脚本。

---

STL;DR;

Put your SQLite.Interop.dll next to the *.exe File.

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

#9

The default installation of the multi-architecture (x86, x64) version of SQLite from NuGet exhibits the behavior that you described. If you would like to load the correct version for actual architecture that the .NET runtime chose to run your application on your machine, then you can give the DLL loader a hint about where to locate the correct library as follows:

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

Add a declaration for the kernel32.dll function call to SetDLLDirectory() before your Program.Main():

为kernel32添加一个声明。在你的程序之前调用SetDLLDirectory()。main ():

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

Then use your own method for determining the correct subdirectory to find the architecture specific version of 'SQLite.Interop.dll'. I use the following code:

然后使用您自己的方法来确定正确的子目录，以找到“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));

#10

I had a similar issue in a multiple projects solution. The SQLite.Interop.dll was necessary for one of the plugins distributed with the software using ClickOnce.

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

As far as debugging in visual studio everything worked fine, but the deployed version was missing the folders x86/ and x64/ containing that DLL.

在visual studio的调试中，一切都很正常，但是部署的版本却丢失了x86/和x64/包含DLL的文件夹。

The solution to have it work after deployment using ClickOnce was to create in the startup project of the solution (also the one being published) these two subfolder, copy into them the DLLs and set them as Content Copy Always.

使用ClickOnce在部署后进行it工作的解决方案是在解决方案的启动项目(也就是正在发布的)中创建这两个子文件夹，并将它们复制到dll中，并始终将它们作为内容复制。

This way the ClickOnce publishing tool automatically includes these files and folders in the manifest and deploys the software with them

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

#11

even if it is an old post, I'd like to share the solution that I found here: http://system.data.sqlite.org/index.html/info/54e52d4c6f

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

If you don't want to read all the issue, the solution is to copy the file "msvcr100.dll" (that can be found in Windows\System32 directory) in the same path as SQLite.Interop.dll.

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

I would advice to read the issue to understand why, and to include the file in your setup but to install it only if the error occurs, I made it an optional component selectable in the setup options.

我建议阅读这个问题，了解原因，并在安装过程中包含文件，但是只有在错误发生时才安装它，我使它成为设置选项中可选的组件选择。

HTH, Formentz

HTH,Formentz

#12

I have started using Costura.Fody to package (.net) assemblies and embed and preload native dlls. This also helps later, with distribution as you can send one file.

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

1. Install Costura Fody from Nuget.

   从Nuget安装Costura Fody。

2. In your C# project create a folder called costrua32. In there add any native dlls you which C# to load.

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

3. Once you have added them to this folder. Click on the properties window and change build action to "Embedded Resource"

   一旦您将它们添加到这个文件夹中。单击“属性”窗口，并将“构建操作”改为“嵌入资源”

4. Finally you need to amend the XML file called FodyWeavers.xml as follows. Here I am specifying load the sql dll first. (note you drop the .dll)

   最后，您需要修改名为FodyWeavers的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.

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

#13

You could also get this error if you are trying to run a 32 bit dll, in a 64 bit project.

如果你想运行一个32位的dll，在一个64位的项目中，你也可以得到这个错误。

I got this when I have placed the same file(SQLite.Interop.dll in 32 bit version) in both the x86 and x64 folder.

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

#14

If you download correct binary for SQLite then copy SQLite.Interop.dll into your Release or Debug folder according to your project build option.

如果您下载了SQLite的正确二进制文件，请复制SQLite.Interop。根据您的项目构建选项，将dll放入您的发布或调试文件夹中。

#15

I've struggled with this for a long time, and, occasionally, I found that the test setting is incorrect. See this image:

我在这个问题上挣扎了很长一段时间，有时候，我发现测试设置是错误的。看到这张图片:

I just uncheck the test setting, and the issue disappears. Otherwise, the exception will occurs. Hopefully, this will help someone. Not sure it's the root cause.

我只是取消了测试设置，这个问题就消失了。否则，将出现异常。希望这能帮助到别人。不确定这是根本原因。

#16

I don't know why this has not been included yet, but I had to do the research and find this out for myself, so hopefully someone will find this answer and be saved the trouble. This was for a WPF app. It worked fine on my Dev box, but did not work on the computer where I was copying it and got the Unable to load DLL 'SQLite.Interop.dll' error. I ported over all of its associated directories and files, directly from my "Debug" folder to this other computer when I got the same error as the OP when I ran it. My "bin" folder that contained my DLLs had been copied to "Debug\bin" and all were included, along with my application files when I did my copying to the other computer using this path, so it was not missing any files.

我不知道为什么这还没有被包括进来，但我必须做研究，自己找到这个答案，所以希望有人能找到这个答案，并能省去麻烦。这是一个WPF的应用程序，它在我的Dev box上运行良好，但在我复制它的计算机上没有工作，因此无法加载DLL的SQLite.Interop。dll的错误。我将所有相关的目录和文件，直接从我的“调试”文件夹移植到另一台计算机上，当我运行它时，我得到了与OP相同的错误。包含我的dll的“bin”文件夹被复制到“Debug\bin”中，所有的文件都包括在我的应用程序文件中，当我使用这条路径复制到其他计算机时，它没有丢失任何文件。

Things I saw said in other answers that did not apply:

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

• I did not use the NuGet package or need to create x86 or x64 folders that it seems that NuGet package creates. My DLLs (System.Data.SQLite and SQLite.Interop.dll, along with System.Data.SQLite.config) are in the "bin" folder in my project and were copied in manually (create "bin" folder in Solution Explorer in VS, paste DLLs into this folder in Windows Explorer, use Add > Existing Item to bring files into VS folder/project). Then I reference them as Referenced Assemblies in my project using that location ("References" > "Add Reference", and browse to one, rinse, repeat for the rest). This ensures my project knows exactly where they are.
• 我没有使用NuGet包，也不需要创建x86或x64文件夹，这看起来是NuGet包创建的。我的dll(System.Data。SQLite和SQLite.Interop。与System.Data.SQLite.config一起在我的项目中的“bin”文件夹中，并在手动复制(在解决方案资源管理器中创建“bin”文件夹，将dll粘贴到Windows资源管理器中的这个文件夹中，使用添加>的现有项目将文件导入到VS文件夹/项目中)。然后，我在我的项目中引用它们作为引用的程序集，使用该位置(“引用”>“添加引用”，然后浏览到其中一个，冲洗，对其余部分重复)。这确保了我的项目知道它们的确切位置。
• I did not need to reference any SQLite DLL file in my app.config or even touch my MyProject.csproj file.
• 我不需要在app.config中引用任何SQLite DLL文件，甚至不需要触摸MyProject。csproj文件。
• I did not even need to specify a particular processor! My project's build is for "Any CPU", even though I have only mixed or 64-bit DLLs and will only be running on Windows 7+, which are 64-bit OSes. (no x86-only/32-bit solely DLLs)
• 我甚至不需要指定一个特定的处理器!我的项目的构建是为了“任何CPU”，即使我只有混合或64位的dll，而且只运行在64位os的Windows 7+上。(没有x86-only / 32位仅仅dll)
• I was already specifying them as "Content" and "copy if newer" for these DLLs when I experienced the OP's error.
• 当我体验到OP的错误时，我已经将这些dll指定为“内容”和“如果更新”。

What I found was this, from https://system.data.sqlite.org/index.html/doc/trunk/www/faq.wiki#q20 :

我发现的是这个，来自https://system.data. sqlite.org/index.html/doc/trunk/www/faq.wiki_20:

(11) Why do I get a DllNotFoundException (for "sqlite3.dll" or "SQLite.Interop.dll") when trying to run my application?

Either the named dynamic link library (DLL) cannot be located or it cannot be loaded due to missing dependencies. Make sure the named dynamic link library is located in the application directory or a directory along the system PATH and try again. Also, be sure the necessary Visual C++ runtime redistributable has been installed unless you are using a dynamic link library that was built statically linked to it.

Emphasis mine on that bolded part inside the paragraph. The target computer was fresh and had no programs loaded except .NET 4.0. Once I installed C++, it was able to complete the commands to SQLite. This should have been one of the first FAQs and part of the pre-requisities, but it was buried at #11. My development computer already had it loaded because it came with Visual Studio, so that's why it worked, there.

我的重点是在这一段中粗放的部分。目标计算机是新鲜的，除了。net 4.0之外没有加载程序。一旦我安装了c++，它就能够完成对SQLite的命令。这应该是第一批常见的常见问题之一，也是前要求的一部分，但它被埋在了11号。我的开发计算机已经加载了它，因为它附带了Visual Studio，所以这就是它工作的原因。

Download:
Visual C++ Redistributable for Visual Studio 2015:
https://www.microsoft.com/en-us/download/details.aspx?id=48145

下载:Visual Studio 2015的Visual c++ Redistributable: https://www.microsoft.com/en-us/download/details.aspx?

Update 3 (cumulative update):
https://www.microsoft.com/en-us/download/details.aspx?id=53587

更新3(累计更新):https://www.microsoft.com/en-us/download/details.aspx?id=53587。

#17

As the SQLite wiki says, your application deployment must be:

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

So you need to follow the rules. Find dll that matches your target platform and put it in location, describes in the picture. Dlls can be found in YourSolution/packages/System.Data.SQLite.Core.%version%/.

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

I had problems with application deployment, so I just added right SQLite.Interop.dll into my project, the added x86 folder to AppplicationFolder in setup project and added file references to dll.

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

#18

I don't know if it's a good answer, but I was able to solve this problem by running my application under an AppDomain with an identity of "Local System".

我不知道这是不是一个好答案，但是我可以通过在AppDomain中运行我的应用程序来解决这个问题，这个应用程序是一个“本地系统”的标识。

#19

I am working on a simple console application to add some test data to an SQLite database and was getting this error. The configuration for the project is "Any CPU". I fixed it by copying the SQLite.Interop.dll to the bin\debug folder. A better way would be to use the method by @Wil, but how do you specify this for "Any CPU" configuration?

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

#20

Could there be contention for the assembly? Check to see whether there's another application with a file lock on the DLL.

是否会有对大会的争夺?检查是否有另一个应用程序与文件锁定在DLL上。

If this is the reason, it should be easy to use a tool like Sysinternal's Process Explorer to discover the offending program.

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

HTH, Clay

HTH,克莱

#21

For reference for anyone looking at this question:

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

If you use the nuget package, it installs a build rule that does the copying for you. (see under System.Data.SQLite.Core.1.0.94.0\build - or whatever version of Core you install).

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

The nuget installer adds the rule to your project file automatically.

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

This still doesn't fix the test case problem though. The DeploymentItem (https://*.com/a/24411049/89584) approach is the only thing that seems to work there.

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

#22

I had this problem because Visual C++ 2010 redistributable no installed in my PC.if you have not already installed Visual c++ 2010 redistributable Download and install this(check x86 or 64 dll).

我遇到了这个问题，因为Visual c++ 2010重新发行版没有安装在我的电脑上。如果您还没有安装Visual c++ 2010可重新分配的下载并安装这个(检查x86或64 dll)。

#23

I ran across this problem, in a solution with a WebAPI/MVC5 web project and a Feature Test project, that both drew off of the same data access (or, 'Core') project. I, like so many others here, am using a copy downloaded via NuGet in Visual Studio 2013.

我在一个WebAPI/MVC5 web项目和一个特性测试项目的解决方案中遇到了这个问题，它们都从相同的数据访问(或者“核心”)项目中退出。我和这里的其他许多人一样，正在使用NuGet在Visual Studio 2013中下载的拷贝。

What I did, was in Visual Studio added a x86 and x64 solution folder to the Feature Test and Web Projects. I then did a Right Click | Add Existing Item..., and added the appropriate SQLite.interop.dll library from ..\SolutionFolder\packages\System.Data.SQLite.Core.1.0.94.0\build\net451\[appropriate architecture] for each of those folders. I then did a Right Click | Properties, and set Copy to Output Directory to Always Copy. The next time I needed to run my feature tests, the tests ran successfully.

我所做的是，在Visual Studio中为特性测试和Web项目添加了一个x86和x64解决方案文件夹。然后我做了一个右击|添加了现有的项目…，并为每个文件夹添加了相应的SQLite.interop.dll库，从.\SolutionFolder\ System.Data.SQLite.Core.1.0.94.0\build\net451\[适当的架构]。然后，我做了一个右击|属性，并将复制到输出目录，以始终复制。下一次我需要运行我的特性测试时，测试就成功运行了。

#24

In short

简而言之

To get this to work also with NCrunch I had to add the Interop.dll versions provided with the NuGet package as additional files in NCrunch configuration.

为了让这个工作和NCrunch一起工作，我必须添加Interop。使用NuGet包提供的dll版本作为NCrunch配置中的附加文件。

My case

我的情况

I had a C# solution with one project directly depending on SQLite (a helper library) and a unit test project that used this helper library. I had installed System.Data.SQLite.Core version 1.0.97.0 as a NuGet package.

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

In my case the workaround provided by Marin got it working in Visual Studio and in CI as well. However this would still provide errors in NCrunch.

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

In NCrunch configuration I added the following path in "Additional files to include" under the unit test projects settings:

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

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

#25

I got the same problem. However, finally, I can fix it. Currently, I use Visual Studio 2013 Community Edition. I just use Add->Existing Item... and browse to where the SQLite.Data.SQLite files are in (my case is 'C:\Program Files (x86)\System.Data.SQLite\2013\bin'). Please don't forget to change type of what you will include to Assembly Files (*.dll; *.pdb). Choose 'SQLite.Interop.dll' in that folder. From there and then, I can continue without any problems at all. Good luck to you all. ^_^ P.S. I create web form application. I haven't tried in window form application or others yet.

我遇到了同样的问题。但是，最后，我可以修复它。目前，我使用Visual Studio 2013 Community Edition。我只是使用添加->现有项目…然后浏览到SQLite.Data。SQLite文件在(我的情况是“C:\程序文件(x86)\System.Data.SQLite\2013\bin”)。请不要忘记将您将要包含的内容更改为程序集文件(*.dll;* .pdb)。选择“SQLite.Interop。dll的文件夹。从那时起，我可以毫无问题地继续下去。祝你们好运。^ _ ^注:我创建web表单应用程序。我还没有在窗体应用程序或其他应用程序中尝试过。

#26

Try to set the platform target to x86 or x64 (and not Any CPU) before you build: Project->Properties->Build->Platform target in Visual Studio.

在构建之前，尝试将平台目标设置为x86或x64(而不是任何CPU): Project->属性->在Visual Studio中构建>平台目标。

#27

Copy "SQLite.Interop.dll" files for both x86 and x64 in debug folder. these files should copy into "x86" and "x64 folders in debug folder.

“SQLite.Interop副本。在debug文件夹中为x86和x64的文件。这些文件应该复制到“x86”和“debug文件夹中的x64文件夹”。

#28

I encountered this problem myself, but it turned out to be another cause:

我自己也遇到过这个问题，但结果却是另一个原因:

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

In this case, the code was (indirectly) called from a web-service hosted by IIS (configured for x86 build). I finally tracked it down to the Application Pool in IIS: Originally I was using "ASP.NET V4.0 Integrated" (which resulted in that error), but when I changed it over to "DefaultAppPool", the problem went away.

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

(Phew!)

(唷!)

#29

I wanted to posted here because of the complexity of this problem. My solution was to roll back to .Net 4.0. I have been testing for 3 days and have not been able to get System.Data.SQLite.Core.1.0.98.0 to work with .Net 4.5 or .Net 4.5.1.

由于这个问题的复杂性，我想把它贴在这里。我的解决方案是回到。net 4.0。我已经测试了3天，还没能得到System.Data.SQLite.Core.1.0.98.0来使用。net 4.5或。net 4.5.1。

The testing was exhaustive on 3 computers, 2 servers one dev PC. I have not been able to get to the source of the issue. I have tried editing the .vsproj file. I have added the SQLite.interop.dll to all folders practically. I have applied the package to all GAC folders, and removed and reapplied individually. Eventually removed.

测试在3台电脑上进行了详尽的测试，2台服务器一台dev PC。我还没能找到问题的根源。我试过编辑.vsproj文件。实际上，我已经将SQLite.interop.dll添加到所有文件夹。我已将此包应用于所有GAC文件夹，并分别删除和重新应用。最终删除。

I do have System.Data.SQLite.Core.1.0.98.0 working with .Net 4.0. I intend to continue to attempt the migration, but I think I will start a new project first and see if I can get it to work in that fashion. This was originally a .Net 3.5 web app, and in my travels I found a good amount of information still referencing that framework.

我有System.Data.SQLite.Core.1.0.98.0，使用。net 4.0。我打算继续尝试迁移，但是我想我将首先启动一个新项目，看看是否能以这种方式工作。这本来是一个。net 3.5的web应用程序，在我的旅行中，我发现大量的信息仍然引用这个框架。

#30

So, my issue was that SQLite was trying to load at design-time in WPF. Since I cared only about x86 environment, I set the CPU preference to that and copied SQLite.Interop.dll from the Nuget package to the root directory of the solution. Restarted the solution and all problems disappeared. So, if you're having design-time issues, put the library into the root directory of your solution.

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

Additionally, I was getting a similar issue during runtime, so I had to place a copy of SQLite.Interop.dll into my project and set it to copy if it's newer in the properties. It appears that x86 and x64 folders provided are completely useless. Further investigation is required, but overall... it's just easier to manually reference SQLite in your project than to use a Nuget package.

另外，在运行时我也遇到了类似的问题，所以我不得不放置一个SQLite.Interop的拷贝。dll进入我的项目，并设置它复制如果它是更新的属性。似乎提供的x86和x64文件夹是完全无用的。需要进一步的调查，但总的来说……在您的项目中手动引用SQLite比使用Nuget包更容易。

Additionally, the official FAQ states the following:

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

(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?

当System.Data(20)。SQLite项目是在Visual Studio中编译和运行的，为什么我要获得DllNotFoundException或一个BadImageFormatException(用于“sqlite3”)。在尝试运行或调试应用程序时，是否需要使用dll或“SQLite.Interop.dll”?

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.

编译并运行在Visual Studio中使用System.Data的解决方案时。SQLite项目(包括测试项目)，选择正确的构建配置和平台非常重要。首先，在Visual Studio中被调试的应用程序不能使用混合模式程序集(也就是说，因为它总是被编译到特定于平台的构建输出目录)。这对于使用相同的源项目文件为多个平台构建二进制文件是必要的。因此，在运行依赖于System.Data的visualstudio中运行托管应用程序时，只需要选择“DebugNativeOnly”或“ReleaseNativeOnly”构建配置。SQLite组装。这些构建配置包含一个自定义的后构建步骤，该步骤将所需的本地程序集复制到托管输出目录(即启用托管的二进制文件)。但是，只有在选定的平台与操作系统(例如:)相匹配时，才会执行这个后构建步骤。32位窗口的“Win32”和64位Windows的“x64”。因此，在尝试在解决方案中运行一个托管项目之前，对所选的构建平台进行双重检查是很好的做法。

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

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