xll
xll

Reputation: 3109

Unable to load 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)

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?

Upvotes: 266

Views: 282717

Answers (30)

TBD
TBD

Reputation: 529

I had this issue and none of the answers on this page helped solve the issue correctly (explanation below). Using Fusion logging I checked where system.data.sqlite.dll is being loaded from (which uses the interop dll) and found that it was being loaded from GAC folder. Removing this from GAC folder, resolved the issue. The reason other solutions aren't good for me is because our app is deployed on millions of computers and only one machine was getting this error. Asking them to place the interop dll in different folders as suggested here resolves the issue but it isn't a good solution since this is one machine and in the upgrade of our app this dll will be removed and I won't change behavior of millions of deployed apps for one machine.

Upvotes: 0

NoeVG
NoeVG

Reputation: 11

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.

Upvotes: 0

lou34964
lou34964

Reputation: 1

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:

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

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

Upvotes: 0

Skyfish
Skyfish

Reputation: 137

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

Upvotes: 1

Daniel
Daniel

Reputation: 12245

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

Upvotes: 0

Doorman
Doorman

Reputation: 29

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.

Upvotes: 0

Rolf Kristensen
Rolf Kristensen

Reputation: 19847

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"

Upvotes: 2

Techie Boy
Techie Boy

Reputation: 159

I had the same issue. Please follow these steps:

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

Reference

Upvotes: 5

Marin
Marin

Reputation: 1308

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.

Upvotes: 94

user3267567
user3267567

Reputation: 550

This is what worked for me.

  1. With Visual Studio open, search and install SQLite.Core via the NUGET Package manager.
  2. Go to Solution Explorer in VS, Right click your PROJECT NAME-->ADD-->NEW FOLDER
  3. Name the folder x64
  4. Repeat the process and add folder and name it x86
  5. 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.
  6. Repeat step 5 for the x86 folder.
  7. Right click the DLL that you just added and select PROPERTIES. In the option Copy to Output Directory, choose Copy always.
  8. 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.

Upvotes: 1

BenCamps
BenCamps

Reputation: 1834

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

Upvotes: 21

Tim Makins
Tim Makins

Reputation: 492

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.

Upvotes: 1

Grigoris Loukidis
Grigoris Loukidis

Reputation: 403

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

Upvotes: 1

Jesse Morales
Jesse Morales

Reputation: 31

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/

Upvotes: 2

Antonin GAVREL
Antonin GAVREL

Reputation: 11219

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

Upvotes: 3

elpezganzo
elpezganzo

Reputation: 367

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.

Upvotes: 0

b.pell
b.pell

Reputation: 4278

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.

Upvotes: 104

Keltar Helviett
Keltar Helviett

Reputation: 708

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

Application deployment

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.

Upvotes: 6

CodingYoshi
CodingYoshi

Reputation: 26989

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:

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

I have no idea why this fixes the issue.

Upvotes: 2

screig
screig

Reputation: 627

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.

  1. Install Costura Fody from Nuget.

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

  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)

    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.

Upvotes: 3

Kugel
Kugel

Reputation: 19814

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.

Upvotes: 163

vapcguy
vapcguy

Reputation: 7537

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

Upvotes: 5

teardrop
teardrop

Reputation: 545

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.

Upvotes: 4

Tony Sun
Tony Sun

Reputation: 19

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

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.

Upvotes: 2

GBGOLC
GBGOLC

Reputation: 600

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
  1. Remove Xml references from the main project's “packages.config” xml file.

This worked for me and keeps my project clean.

Upvotes: 0

Ahmad Aghazadeh
Ahmad Aghazadeh

Reputation: 17131

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

Upvotes: 2

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;

  1. Set all Projects of your solution to x86 or x64 in the build options.

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

Upvotes: 9

Filippo Vigani
Filippo Vigani

Reputation: 1004

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.

Upvotes: 18

thardes2
thardes2

Reputation: 1186

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.

Upvotes: 2

DharmaTurtle
DharmaTurtle

Reputation: 8357

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.

Upvotes: 0

Related Questions