Unable to load DLL 'SQLite.Interop.dll'

Question

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)

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

Once exception starts to appear, it appears constantly - in debug and release and running application within or outside 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.

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

Yes, it's set to copy always. I have x64 and x86 folders in bin/debug. And it works mostly, but sometimes just stops to work. Probably something is blocking the access to the dll, I will try to find it out next time it stops to work. As I said it may work days without any problems. — xll, Oct 23 '12 at 14:18
I got this error right out of the box after adding the SQLite nuget package to a new console project. Manually copying SQLite.Interop.dll from the x86 folder up one level allows the app to run. Seems strange to me that this would be so broken. — lesscode, Dec 22 '12 at 04:53
@Wayne Yes, this definitely helps. But in my case, we are working together on the project, and my friend is using x86, while me x64 OS. And as I noticed, it just stops to work sometimes. Though it didnt happen to me last month. — xll, Dec 22 '12 at 09:03
If you download correct binary for SQLite then copy SQLite.Interop.dll into your Release or Debug folder according to your project build option. — Elshan, Mar 02 '14 at 07:43
This is such a random bug... sometimes it occurs and sometimes it doesn't for my project. Tried everything. — B.K., Oct 20 '14 at 04:53
I ran into several problems like this. The solution that worked for me was to use the statically linked version of the library. — developerwjk, Jan 26 '15 at 20:28
For me it works on run and on debug, but not on d:DesignInstance (wpf). I fixed it by copying the dll up into the project directory, but after rebooting, that's not working anymore. I don't get it. — Patrick, Apr 13 '15 at 19:01
OK... I changed it to x86 only - still not working. Reverted the change... f'ing WORKS! — Patrick, Apr 13 '15 at 21:31

score 160 · Answer 1 · edited Mar 27 '17 at 14:36

160

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.

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.

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

edited Mar 27 '17 at 14:36

Marcos Dimitrio

6,651
5
38
62

answered Sep 01 '13 at 14:03

Kugel

19,354
16
71
103

14

It worked for me after I added the reference to SQLite Core with NuGet to the main project. – Luca Cremonesi May 20 '15 at 22:51
Adding sqllite.core to main project worked for me on my WPF solution – Dipu Raj Oct 21 '16 at 06:35
I had to do both install-package Sqlite as well as Install-Package System.Data.SQLite.Core into my website even though the db calls are in a library... – Dec 16 '16 at 01:31
This should be the answer. – Bobby Turkalino Jul 03 '17 at 14:52
This worked for me using VS 2017. I installed System.Data.SQLite into one project and only needed System.Data.SQLite.Core referenced in my startup project. – ahwm Apr 05 '18 at 16:47
4

What do you mean by "main site" project? In my case I am doing desktop work. Do you mean the "startup" project? – StayOnTarget Dec 17 '18 at 13:40
1

Well you're right and it is not ideal. I tried to copy the interop dll from the post build event and it doesn't even work. These dll seem to appear in the x86/x64 AFTER the post-build event is called .. somewhat useless. – DarkUrse Mar 11 '19 at 09:15
@DaveInCaz - That worked for me. I have a command line app that calls a dll that uses sqlite. Including sqlite in the command line app solved this issue. – TomDestry Aug 17 '19 at 16:33
This worked for me after installing the System.Data.SQLite.Core nuget package to my Startup project (VS 2019) – Kibria Sep 05 '19 at 10:27
It worked for me too. But why? If I have added Nuget to by BL library and referenced that BL in Web/Desktop project, it should bring that files/DLLs – Milind Thakkar Dec 30 '20 at 09:41
@LucaCremonesi - Thank you, that was exactly the cause of this error in my own project. For everyone's reference, System.Data.SQLite is referenced and used only in a DLL that is part of the Solution, but I did have to add System.Data.SQLite.Core to the MAIN Project (in this case, a Forms Project) in order to fix this Interop DLL Exception. – El-Ahrairah May 03 '22 at 02:04

score 91 · Answer 2 · edited Nov 17 '20 at 14:22

91

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

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

edited Nov 17 '20 at 14:22

software_writer

3,941
9
38
64

answered Jan 22 '15 at 15:26

Marin

1,268
12
7

Agreed. I'm using the 'Sqlite.Net PCL' package but found I also needed 'System.Data.SQLite Core (x86/x64)'. I also had to change the project(s) referencing it to use a Platform target of 'x86' or 'x64', rather than 'Any CPU'. – Andrew Stephens Jun 08 '15 at 10:02
2

Tried quite a few solutions posted here, this one actually worked out best. – Batman Aug 26 '15 at 17:24
2

How can you add a dependency like that? never done it (VS2013) – jpgrassi Sep 02 '15 at 18:15
7

Go to Tools -> NuGet Package Manager -> Manage NuGet Packages for Solution... -> Online -> All. Then Search for sqlite and add System.Data.SQLite Core (x86/x64). – Marin Sep 04 '15 at 11:22
1

Did you mean"System.Data.SQLite.Core" ? I don't see any package called "Sqlite.Core". Thanks – StayOnTarget Dec 17 '18 at 13:46
@Marin Online? I don't see that in Manage Nuget Packages for Solution – KansaiRobot Feb 14 '19 at 06:33
3

Also, I think SQLite Core is installed. and yet fails :( – KansaiRobot Feb 14 '19 at 06:33
It has probably changed a bit since 2015 (as I was using VS2012). Unfortunately, I don't have VS installed any more so I can't check how it is done now. – Marin Feb 15 '19 at 10:34
Yes for example in my case I have DLL which uses SQLite -- whose build correctly copies the interop DLL to its bin/release/x64 and bin/release/x32 directories. But then I also have a separate test DLL, which contains the unit tests -- the unit test's build copies the system under test but not the interop DLLs, to the release directory of the test DLL. – ChrisW Dec 03 '20 at 01:35
Excellent Marin, your comment helped me greatly! – RotatingWheel Jan 14 '22 at 13:42

score 88 · Accepted Answer · answered Feb 28 '18 at 21:54

88

So, after adding the NuGet the deployment doesn't copy down the Interops. You can add this to your csproj file and it should fix that behavior:

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

If you look in the source for NuGet for SQLite you can see what these are doing specifically. This allowed me to get a deploy working with ASP.Net Core.

answered Feb 28 '18 at 21:54

b.pell

3,873
2
28
39

13

ContentSQLiteInteropFiles is the answer. Most of the top answers are guesswork. – Corey Alix Nov 20 '18 at 15:38
7

Yes, ContentSQLiteInteropFiles is the answer. 1. This should be the accepted answer 2. On the other hand, it should be investigated, that as a nuget package how to make this work automatically, or at least document the need for this configuration. – gerleim May 03 '19 at 11:20
Should be the accepted answer. Super simple. 1. unload project 2. add the above to csproj 3. reload project. it's that easy... – BillRuhl Apr 28 '20 at 16:37
2

Note that this solution is for "old" style projects only. For an answer that works for "new" style projects too, see https://stackoverflow.com/a/60176344/448129 – MajorRefactoring May 05 '21 at 18:05
How does one arrive at such a solution? Is there some documentation as to what exactly adding this code does? Would very much appreciate more info. – tutiplain Aug 31 '21 at 15:44
It does seem to work, and yet I still get a failure at runtime. Manually copying SQLite.Interop.dll to the Debug/Release dir is the only thing that works for me. – tekHedd Jan 11 '22 at 21:42

Caleb Kiage · Answer 4 · 2013-03-04T12:55:20.793

50

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:

Open the project designer in Visual Studio. Details on how to do it can be found here.
Click on the Build tab.
Disable the prefer 32-bit option.

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.

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.

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>

edited Mar 04 '13 at 12:55

answered Mar 03 '13 at 20:54

Caleb Kiage

1,422
12
17

I am using VS 2010, there is no such option. – xll Mar 04 '13 at 08:01
@xll, I edited the answer for clarification. Check if the edit clears things up. – Caleb Kiage Mar 05 '13 at 19:41
I had this problem when I tried to start application in VS 2012 debug mode with target platform AnyCPU, and disabling the `Prefer 32-bit` option worked for me. – Hogan May 01 '13 at 12:37
The option was not checked by default, but checking it then unchecking it worked! – Pete Kirkham Jun 14 '13 at 13:57
10

In VS2012 this option is grayed out for me. – Kugel Sep 01 '13 at 13:02
7

The option is only enabled on EXE projects, but I think most of us have this issue with unit test projects. – Brannon Oct 02 '14 at 14:33
1

Was greyed out for me in a WPF project in VS Pro 2015. `.csproj` file had it set to `false` already, but still had the error. – vapcguy Feb 01 '17 at 23:45

score 35 · Answer 5 · answered Sep 25 '13 at 23:52

35

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.

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

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

answered Sep 25 '13 at 23:52

Wil

556
6
12

for "SQLite.Interop.dll" is not there in project's .csproj file. still i tried to add your solution but didn't work :( – aru Mar 28 '15 at 09:13
This will not work in VS2012, the elements do not exist. – htm11h Aug 27 '15 at 18:14
Thank you very much. Works in 2015 vs. – Jevgenij Kononov Dec 14 '17 at 10:56
2

I tried using a based on the build type but it was not working for unit tests. The OutDir was not correct. By copying the "x86" and "x64" folders I guess sqlite (or maybe .net) found what it needed. Thank you so much! – Corey Alix Sep 14 '20 at 22:26

score 27 · Answer 6 · answered Jun 04 '14 at 17:33

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

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

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

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.

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.

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

The message I got was telling me that those files were missing but I thought it was a permission issue. Once I saw your message i realized they never actually made it to the server when I deployed. — Stradas, Feb 12 '15 at 21:39
My near identical solution was to add x86 and x64 folders to my startup project, then add the x86 interop and x64 interop files within their respective folders. I set the files' option to "content" and "build always." This is the only way I could get my Windows Forms app to connect to an embedded s3db database file when I deployed the app with ClickOnce to other PC's. Frustratingly, I didn't have an SQLite error when I developed and tested the app on my PC. — David Alan Condit, Mar 25 '16 at 02:45
This is the answer that helps me understand my problem, although my fix is a bit different. My problem is that I added the system.data.Sqlite.dll manually. In this way the Sqlite.Interop.dll is not automatically copied to \x86 and x64. The fix is to delete the reference and add it by Nuget. — Susan Wang, Aug 30 '18 at 00:23

Michael Bromley · Answer 7 · 2014-08-28T12:31:25.743

19

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.

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

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.

All is green. All is good.

edited Aug 28 '14 at 12:31

answered Jun 25 '14 at 14:12

Michael Bromley

4,792
4
35
57

1

This solution works only if you are using the Microsoft.VisualStudio.TestTools.UnitTesting namespace – sapbucket Sep 23 '14 at 16:13
4

This is a correct solution if you're using MSTest. SQLite worked fine, finding the SQLite.Interop.dll with no issue, until I used DeploymentItem("some.csv") for a test. Including the .csv file in that way triggered MSTest to copy all referenced dlls over to the TestResults directory. Since SQLite.Interop.dll is not referenced in the project (and cannot be since it's unmanaged code), it never got copied over. – Johann Apr 16 '15 at 23:56
Your best bet is to add two lines, one for each architecture. That protects you in the event the test runner happens to be running 64-bit. – Kirk Woll Oct 20 '16 at 22:26

score 18 · Answer 8 · answered Dec 23 '15 at 15:51

18

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.

answered Dec 23 '15 at 15:51

Filippo Vigani

904
1
9
22

If you get an error when doing this, removing my SQLite DLLs/references and completely reinstalling them from nuget did the trick for me – KayakinKoder Jun 09 '16 at 05:43
reinstall sqllite core help to me too. Occured at VS2012. VS didn't include x62 version to web deploy package – Andrey Ravkov Sep 01 '16 at 08:07
Fixed for me too in VS2015 Professional. – Rahul Kishore Sep 19 '17 at 22:12

score 16 · Answer 9 · answered Feb 11 '20 at 19:49

old project file format

i.e. projects beginning with <Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

Add the following to your csproj on your "main"/root project

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

new SDK project file format

i.e. projects beginning with <Project Sdk="Microsoft.NET.Sdk.*">

Add PrivateAssets="none" to each ProjectReference/PackageImport in the dependency chain down to the System.Data.Sqlite PackageImport

ex:

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

ouput successfully show: Copying file from "..\packages\System.Data.SQLite.Core.1.0.105.2\build\net451\x64\SQLite.Interop.dll" to "XXProject\release\x64\SQLite.Interop.dll". Copying file from "..\packages\System.Data.SQLite.Core.1.0.105.2\build\net451\x86\SQLite.Interop.dll" to "XXProject\release\x86\SQLite.Interop.dll". — John Jang, Jul 08 '20 at 07:15
Please EVBD use this solution, and never just copying the dll manually!! — John Jang, Jul 08 '20 at 07:16

score 10 · Answer 10 · answered May 27 '14 at 18:56

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.

As far as debugging in visual studio everything worked fine, but the deployed version was missing the folders x86/ and x64/ containing that 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.

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

this was the only solution that worked for me... and boy.. was it a pain to debug when your app just closes on a user's pc. — stoic, Apr 12 '15 at 17:03

score 9 · Answer 11 · edited Jun 20 '20 at 09:12

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.

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

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

TL;DR;

Set all Projects of your solution to x86 or x64 in the build options.
Add following Post-Build-Script to the Project with the SQLite nuget Package:

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

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

STL;DR;

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

score 7 · Answer 12 · answered Jul 09 '13 at 22:50

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:

Add a declaration for the kernel32.dll function call to SetDLLDirectory() before your Program.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:

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

score 5 · Answer 13 · answered Nov 22 '13 at 12:33

5

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

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.

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

answered Nov 22 '13 at 12:33

Formentz

1,083
1
14
20

1

Thanks so much for this, I tried everything else and this was the solution – David Benko May 07 '15 at 15:26
Thankyou. This solution fix my problem. – Murat Özbayraktar Sep 08 '20 at 10:39

vapcguy · Answer 14 · 2017-02-03T19:36:12.193

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.

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.
I did not need to reference any SQLite DLL file in my app.config or even touch my MyProject.csproj file.
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)
I was already specifying them as "Content" and "copy if newer" for these DLLs when I experienced the OP's error.

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

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

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

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

score 5 · Answer 15 · answered Sep 13 '17 at 06:42

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

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%/.

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.

score 5 · Answer 16 · answered Dec 03 '20 at 07:34

5

I had the same issue. Please follow these steps:

Make sure you have installed System.Data.SQLite.Core package by SQLite Development Team from NuGet.
Go to project solution and try to locate build folder inside packages folder
Check your project framework and pick the desired SQLite.Interop.dll and place it in your debug/release folder

Reference

answered Dec 03 '20 at 07:34

Techie Boy

139
1
12

Thanks, I was using different version of .net framework. The reference video was helpful. – Salman Dec 04 '20 at 13:48

score 4 · Answer 17 · answered Jan 17 '17 at 15:03

4

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.

answered Jan 17 '17 at 15:03

teardrop

545
3
9
18

score 3 · Answer 18 · answered Nov 01 '13 at 07:50

3

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

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

answered Nov 01 '13 at 07:50

Morten Holmgaard

7,484
8
63
85

score 3 · Answer 19 · answered Mar 02 '14 at 07:22

3

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

answered Mar 02 '14 at 07:22

Elshan

7,339
4
71
106

screig · Answer 20 · 2017-07-24T11:45:45.750

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.

Install Costura Fody from Nuget.
In your C# project create a folder called costrua32. In there add any native dlls you which C# to load.
Once you have added them to this folder. Click on the properties window and change build action to "Embedded Resource"
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)
```
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.

Folder name should be costura32, documentation https://github.com/Fody/Costura#native-libraries-and-preloadorder — Elton Saunders, Mar 24 '16 at 15:54

score 3 · Answer 21 · answered Aug 29 '18 at 11:38

3

Also added the dll to the test project (through Nuget Manager) and it fixed it.

answered Aug 29 '18 at 11:38

Antonin GAVREL

9,682
8
54
81

score 2 · Answer 22 · edited Mar 02 '14 at 07:14

2

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

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

HTH, Clay

edited Mar 02 '14 at 07:14

Elshan

7,339
4
71
106

answered Oct 23 '12 at 18:31

Clay Compton

1,266
9
6

score 2 · Answer 23 · answered Jan 25 '15 at 12:03

2

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

answered Jan 25 '15 at 12:03

Ali Yousefi

2,355
2
32
47

Yes. This was my case too ... only mine was requireing Visual C++ 2010 redistributable SP1. Best soulution is to read carefully which runtime is required for your version. For example here: http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki – Velja Radenkovic May 28 '15 at 11:52
Latest link: https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads – didge Feb 10 '20 at 15:53

score 2 · Answer 24 · answered Aug 16 '15 at 11:58

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.

score 2 · Answer 25 · answered Dec 22 '15 at 09:50

2

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.

answered Dec 22 '15 at 09:50

thardes2

1,162
12
28

score 2 · Answer 26 · answered Sep 19 '16 at 06:39

2

Copy SQLite.Interop.dll in project directory.

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

answered Sep 19 '16 at 06:39

Ahmad Aghazadeh

16,571
12
101
98

I had to give IIS_APPPOOL Edit permissions to Bin file to solve the problem. Just copying the ddl was causing an Access Denied to the dll – AlexanderD Oct 05 '18 at 12:34
Adding these file has solved the issues, but this is a temporary solution. – Kartik Goyal Nov 21 '18 at 07:28

score 2 · Answer 27 · edited Oct 24 '16 at 01:30

2

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.

edited Oct 24 '16 at 01:30

Simon MᶜKenzie

8,344
13
50
77

answered Oct 22 '16 at 10:46

Tony Sun

19
2

1

While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - [From Review](/review/low-quality-posts/14064227) – Robert Columbia Oct 22 '16 at 13:15
In my case, the testsettings file is wrong: – Tony Sun Oct 24 '16 at 02:15

score 2 · Answer 28 · answered Jul 28 '17 at 20:52

My application is a web application (ASP.NET MVC) and I had to change the application pool to run under LocalSystem instead of ApplicationPoolIdentity. To do this:

Open IIS Manager
Find the Application Pool your site is running under.
Click Advanced Settings from the actions
Change Identity to LocalSystem

I have no idea why this fixes the issue.

Jesse Morales · Answer 29 · 2018-09-27T23:01:12.173

My situation was a little unique. I was running an application inside a docker container and kept getting the following error

System.DllNotFoundException : Unable to load shared library 'SQLite.Interop.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libSQLite.Interop.dll: cannot open shared object file: No such file or directory

So I set LD_DEBUG=libs to find out what folders System.Data.SQLite.dll was looking in to find SQLite.Interop.dll.

You can find info on setting LD_DEBUG here: http://www.bnikolic.co.uk/blog/linux-ld-debug.html

Once I did that I realized that SQLite.Interop.dll was being found just fine. The DLL that wasn't being found was libSQLite.Interop.dll. I should have read the entire error message.

Hours of Googling later I found this guide on how to compile the missing DLL from the SQLite source code.

Note that the file that was actually missing was libSQLite.Interop.dll.so

Anyway when you compile the source code you get libSQLite.Interop.so which you need to rename to libSQLite.Interop.dll.so and put it in the directory that it's looking in which you can find by setting LD_DEBUG.

For me the directory that System.Data.SQLite.dll was looking in was /usr/lib/x86_64-linux-gnu/

This worked for me on a Linux machine, thanks! – akac Jan 28 '21 at 11:53 — akac, Jan 28 '21 at 11:53

Rolf Kristensen · Answer 30 · 2021-07-28T20:09:59.547

Upgrading to Visual Studio 2019 ver. 16.10 caused the issue for me, where msbuild reported the following for the System.Data.SQLite.Core-package:

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

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

Microsoft says the bug has been fixed with ver. 16.10.4. Now just have to wait for AppVeyor to update their Visual Studio Images (Until then one can use Previous Visual Studio 2019).

Now AppVeyor is using broken dotnet-build-engine for both current and previous Visual Studio 2019-image. Now one have to explicit install 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"

score 1 · Answer 31 · answered Mar 31 '13 at 22:31

1

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

answered Mar 31 '13 at 22:31

Jesse McDowell

43
1
6

score 1 · Answer 32 · answered Oct 17 '13 at 18:07

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?

score 1 · Answer 33 · answered Jan 08 '15 at 20:44

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

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

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

score 1 · Answer 34 · answered Feb 23 '15 at 16:57

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.

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.

score 1 · Answer 35 · edited May 23 '17 at 12:26

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.

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.

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.

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

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

Stumbled across the same problem and knew it has something to do with ncrunch. Solved my some time. — Jürgen Steinblock, Sep 16 '15 at 15:08

score 1 · Answer 36 · answered Aug 27 '15 at 16:22

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.

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.

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.

If you look at the nuget package for 4.5.1, it doesn't have the dll in the build directory. It has it for literally every other version of .net. I "fixed" the problem by going up to 4.7.1. — Nielsvh, May 04 '20 at 18:19
FYI 4.7.1 wasn't available back then. No need to post on such an old thread. — htm11h, Jul 30 '20 at 18:38

score 1 · Answer 37 · answered Sep 10 '19 at 10:53

1

You do need to install System.Data.SQLite.Core via NuGet. If you use InnoSetup, make sure that you have the following lines in the [Files] section of the .iss file:

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

Change 'YourProjectPath' for the path to your project.

answered Sep 10 '19 at 10:53

Tim Makins

394
4
12

The Answer ABOVE is IMHO the only Solution per my Issue which has NOT been able to be resolved by MS Development Team here is a link to my question https://stackoverflow.com/questions/63679859/file-not-found-error-system-data-sqlite-version-1-0-113-0 and a Strong suggestion is to use Inno Setup back in the dark ages we called this dll HELL when using VB 6 that is when I learned to use Inno Setup Here is good video if your a beginner https://www.youtube.com/watch?v=z5g_79_nD-g – Vector Sep 06 '20 at 01:29

score 1 · Answer 38 · answered Oct 06 '20 at 20:06

This is what worked for me.

With Visual Studio open, search and install SQLite.Core via the NUGET Package manager.
Go to Solution Explorer in VS, Right click your PROJECT NAME-->ADD-->NEW FOLDER
Name the folder x64
Repeat the process and add folder and name it x86
Right click the x64 folder-->ADD-->EXISTING ITEM Then browse to the DEBUG FOLDER. You will find the x64 folder. Open it and select the "SQLite.Interop.dll" file then hit OK.
Repeat step 5 for the x86 folder.
Right click the DLL that you just added and select PROPERTIES. In the option Copy to Output Directory, choose Copy always.
Repeat step 7 for both DLLs in x64 and x86 folder.

Next time you build the project and take to another computer, it should work fine.

For me it was enough to install SQLite.Core – Eduardas Šlutas Dec 29 '21 at 15:27 — Eduardas Šlutas, Dec 29 '21 at 15:27

score 1 · Answer 39 · answered Nov 12 '21 at 11:18

1

I found that when I allowed Nuget to update SQLite to 1.0.115.5 my project no longer needed the 'SQLite.Interop.dll'.

answered Nov 12 '21 at 11:18

Skyfish

119
2
4

score 0 · Answer 40 · answered Jul 21 '15 at 19:41

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.

(Phew!)

I am using DefaultAppPool and getting the error, tread lightly! — htm11h, Aug 27 '15 at 16:17

B.K. · Answer 41 · 2015-09-23T05:26:46.627

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.

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.

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?

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

score 0 · Answer 42 · answered Sep 27 '15 at 02:02

Mine didn't work for unit tests either, and for some reason Michael Bromley's answer involving DeploymentItem attribute didn't work. However, I got it working using test settings. In VS2013, add a new item to your solution and search for "settings" and select the "Test Settings" template file. Name it "SqliteUnitTests" or something and open it. Select "Deployment" off to the right, and add Directory/File. Add paths/directories to your SQLite.Interop.dll file. For me, I added two paths, one each for Project\bin\Debug\x64 and Console\bin\Debug\x86. You may also want to add your Sqlite file, depending on how you expect your unit test/solution to access the file.

score 0 · Answer 43 · answered Sep 22 '16 at 11:50

Expanding on Kugel’s answer which worked for me (VS2015 Enterprise) leveraging SQLite from a dll the Nuget package can be removed from the main project after building and testing:

1.Install Nuget package to main project.

Install-Package System.Data.SQLite

2.Build Application and test that your Sqlite connection is working:

select * from sqlite_master

3.Uninstall Nuget package from the main build.

UnInstall-Package System.Data.SQLite

4.Manually remove the dll references for SQLite and EntityFramework:

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

Remove Xml references from the main project's “packages.config” xml file.

This worked for me and keeps my project clean.

score 0 · Answer 44 · answered Mar 06 '18 at 05:20

In the Nuget package of SQLLite Core there is a the file System.Data.SQLite.Core.targets . Just include this in all projects that use the this library and all libraries that used your library.

In yours .csproj or .vbproj files add: Every time you compile in your bin will added x86 and x64 directory with the SQLite.Interop.dll file.

score 0 · Answer 45 · answered Sep 06 '19 at 09:28

0

Just worked this for me : Install-Package System.Data.SQLite.Core on Package Manager Console.

answered Sep 06 '19 at 09:28

Grigoris Loukidis

383
2
7
23

score 0 · Answer 46 · answered Sep 08 '21 at 19:41

I tried pretty much all of the solutions here without any luck. Finally solved it by putting a copy of the SQLite.Interop.dll corresponding to my selected platform directly under the root of my setup project.

I have no idea why it worked but it did.

score 0 · Answer 47 · answered Sep 13 '21 at 23:11

Over 30 answers, and yet I solved it in a different way.

I had 2 separate projects. A Windows Service, and a Windows Forms app. The App references the WS project, and both reference the SQLite Core nuget package.

When building the WS project, the x64 and x32 folders are there. But when building the App, the folders don't show up.

Checking the answers here, I couldn't make them work. But I figured out that the following snippet was present in the WS project, and was missing in the App project. I added it, and the folders now show up correctly.

<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')" />

score 0 · Answer 48 · answered Dec 01 '22 at 17:33

I came up with a solution.

In my case, I am using Microsoft Visual Studio Installer Project. The setup project does not see the x64 and x86 folders and contents from primary outputs.

Solution:

Add both the x64 and x86 folders to the Application Folder in Setup.
Add the contents of both folders.

This will allow the setup to copy the DLL files needed for SQLite to work.

score 0 · Answer 49 · edited Dec 21 '22 at 07:49

0

One solution that worked for me was to install System.Data.SQLite from the nuget package.

Import the .dlls of the project you want to import and install System.Data.SQLite.

This will install the ddl compatible and updated with your solution/project.

edited Dec 21 '22 at 07:49

Andreas

5,393
9
44
53

answered Dec 18 '22 at 03:12

NoeVG

11
2

Unable to load DLL 'SQLite.Interop.dll'

49 Answers49

old project file format

new SDK project file format

TL;DR;

STL;DR;

Linked

Related