System.Data.SQLite

I downloaded sqlite-dotnet-x64-1006900.exe and, after uninstalling the previous version of Sqlite for .NET, I installed it on a WinX64 v.7 SP1 with Framework 4.1, without problems. I successfuly recompiled all my programs associated with the Sqlite assembly in release mode.
When I executed the programs, all of them issues the next error:  System.DllNotFoundException: Unable to load DLL 'SQLite.Interop.DLL': The specified module could not be found. (Exception from HRESULT:0x8007007E) at System.Data-SQLite.UnsafeNativeMethods.sqlite3_open_interop(Byte[] utf8Filename, Int32 flags, IntPtr& db) at System.Data.SQLite.SQLite3.Open(String strFilename, SQLiteOpenFlagsEnum flags, Int32 max maxPoolSize, Boolean usePool) in  ....

<hr /><i>shane added on 2011-04-15 17:36:29 UTC:</i><br />
You need to place SQLite.Interop.dll where System.Data.SQLite.dll can find it.   For now, we are no longer combining them into a single DLL. 

<hr /><i>anonymous added on 2011-04-16 05:24:01 UTC:</i><br />
I am having similar issues. Assembly.LoadWithPartialName("System.Data.SQLite") used to work in 1.0.66, now it fails due to SQLite.Interop.dll. Just a thought: should not SQLite.Interop.dll be in the GAC, too? It is not.

<hr /><i>anonymous added on 2011-04-16 05:32:36 UTC:</i><br />
I have manually copied "C:\Program Files\System.Data.SQLite\bin\SQLite.Interop.dll" to C:\Windows\assembly\GAC_MSIL\System.Data.SQLite\1.0.69.0__db937bc2d44ff139 where System.Data.SQLite.dll is installed and the problem has gone.

This issue looks an installation bug (if the "Install to GAC" option is checked).


<hr /><i>anonymous added on 2011-04-16 23:07:08 UTC:</i><br />
Shane, I follow your indications and it works well now. Thanks.

<hr /><i>anonymous added on 2011-04-23 11:00:59 UTC:</i><br />
I downloaded sqlite-dotnet-x86-1007000.exe on win 7 32-bits and after installation I still miss SQLite.Interop.dll in C:\Windows\assembly where I find  System.data.SQLite and System.Data.SQLite.Linq.
The following Powershell Scrip

[System.Reflection.Assembly]::LoadWithPartialName("System.Data.SQLite") 
$ConnectionString = "Data Source=C:\Var\sqlite_ff4\places.sqlite"
$conn=new-object System.Data.SQLite.SQLiteConnection 
$conn.ConnectionString=$ConnectionString 
$conn.Open() 

gives 

GAC    Version        Location                                                                                                                                                                  
---    -------        --------                                                                                                                                                                  
True   v2.0.50727     C:\Windows\assembly\GAC_MSIL\System.Data.SQLite\1.0.70.0__db937bc2d44ff139\System.Data.SQLite.dll                                                                         
Exception calling "Open" with "0" argument(s): "Unable to load DLL 'SQLite.Interop.DLL': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"
At line:5 char:11
+ $conn.Open <<<< () 
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException
 

I thought this problem was resolved http://system.data.sqlite.org/index.html/tktview?name=54e52d4c6f

BTW: I didn't succeed with the work arounds either.



<hr /><i>anonymous added on 2011-04-25 12:14:53 UTC:</i><br />
Why is this ticket closed? There is still an issue. If users choose "Install to GAC" on installation then they expect Assembly.LoadWithPartialName("System.Data.SQLite") to work out of the box. This is not the case. At least there are several evidences that the problem exists after installation.

<hr /><i>anonymous added on 2011-04-25 15:48:27 UTC:</i><br />
From Another "Anonymous" -- It doesn't matter if the "GAC' selection is made or not -- the problem remains.

<hr /><i>anonymous added on 2011-04-25 15:51:29 UTC:</i><br />
Setting Status to "Open".

<hr /><i>anonymous added on 2011-04-25 18:25:43 UTC:</i><br />
Changed resolution to "Open".

<hr /><i>anonymous added on 2011-04-25 19:39:37 UTC:</i><br />
The issue also exists in 1.0.70.0,

I am using .NET 3.0 on Vista SP1 and having no luck with the workaround.

<hr /><i>anonymous added on 2011-04-27 00:42:02 UTC:</i><br />
I installed SQLite "sqlite-dotnet-x86-1007000.exe" on my XP SP3 laptop (x86) and got the same issue as the rest..
Tried the work arrounds with the same result..


<hr /><i>shane added on 2011-04-27 14:17:54 UTC:</i><br />
The interop DLL contains unmanaged code and can not be installed in the GAC.   System.Data.SQLite.dll makes calls to this DLL, and thus needs to be able to find it.  Some possible work arounds:

1) try copying the interop DLL to the same directory as where the SDS DLL was installed
2) try adding the directory containing the interop DLL to the path

If those fail, please try this and report the results:

Run the appropriate "setup" from the downloads page and install to a temp directory like "C:\temp\System.Data.SQLite" - this is so it is writeable.
Choose all the default options for installation.  Run the test utility - "C:\temp\System.Data.SQLite\bin\test.exe".   Does it work?  What errors are reported?


<hr /><i>anonymous added on 2011-04-27 19:48:20 UTC:</i><br />
Kribo (XP SP3 laptop)

I downloaded the source files [sqlite-dotnetsrc-1007000.zip] and 
made a solution buid (release) and discoverd that there's 
no sign of any "SQLite.Interop.dll" files.

I also tried to refactor the [sqlite-dotnetsrc-1007000.exe] 
to discover if the dll file was included, but to no succes 

Dit the first test : installed the .exe in the C:\Temp 
and ran the test.exe .... no faults

So I did the next best thing..
Copied the [SQLite.Interop.dll] to my dotNet project\bin\debug\ directory
and ran the F5 again... AND WITH SUCCES ... cool

I also tried to incude the [SQLite.Interop.dll] as a reference with my 
dotNet appi but got the following 


---------------------------
Microsoft Visual Studio
---------------------------
A reference to 'C:\Temp\System.Data.SQLite\bin\SQLite.Interop.dll' could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.
---------------------------
OK   
---------------------------

Request / Question
by making it accesable wil the issue be solved ?

grtz
Kribo

<hr /><i>anonymous added on 2011-04-27 20:18:17 UTC:</i><br />
Kribo

So conclusion ..
When one makes a dotNet appi using embedded SQLite.
One must add an "existing item" to your project.
And this directly uder the root
   MySolution
     MyProject
       SQLite.Interop.DLL

And one must ulter the property of the item "SQLite.Interop.DLL"
  Copy to Output Directory -> Copy always

And "System.Data.SQLite.dll" one adds as a reference to ones project..

After doing so your appi should run..

Kind regards

Kribo

<hr /><i>anonymous claiming to be Helga added on 2011-04-28 13:14:27 UTC:</i><br />
Hello all,
I noticed the same error <b>'System.DllNotFoundException: Unable to load DLL 'SQLite.Interop.DLL''</b> reproduced with 1.0.70 and 1.0.71 versions. Right after installation I ran your test utility <i>bin\test.exe</i>: everything’s OK with x64 Windows, but on x32 this error occurs immediately.

I downloaded <b>sqlite-dotnetsrc-1007100.zip</b> and tried to compile a build in Release mode, but it was impossible to compile the SQLite.Designer there.

If the SQLite.Designer project is excluded from the solution, everything is compiled successfully, but as a result two assemblies of System.Data.SQLite.dll come out. Your test utility <i>bin\test.exe</i> works OK with x32 Windows if only one of System.Data.SQLite.dlls (the bigger one) is renamed into SQLite.Interop.dll.

Could you please fix this bug and make a new build in Release mode [92cf2525cb]? Thank you!

<hr /><i>anonymous added on 2011-04-28 18:39:41 UTC:</i><br />
Win XP SP2
Installed lastest build and ran test.exe.  Got "Unable to load DLL "SQLite.Interop.DLL".  HRESULT 0x8007007E.  Copies the interop assembly to every directory I can think of and still get the error.

Also, I'm not hot on the "add the directory to your path" solution as none of my other .NET applications require being added to the path.

<hr /><i>anonymous added on 2011-04-28 21:17:50 UTC:</i><br />
We were having some users get the 'Unable to load DLL' error and some not. The SQLite.Interop.dll was in the same directory as our executable. That was not our problem. The problem was some are missing a dependency: MSVCR100.dll.

Using Dependency Walker from http://dependencywalker.com/ to look at SQLite.Interop.dll (x86 and x64) shows that it depends on MSVCR100.dll.

The old 1.0.66.0 version of System.Data.SQLite.dll does not have this dependency. With the current build, we would have to redistribute that MSVCR100.dll also or run an installer from Microsoft.

Solution: 
From: http://stackoverflow.com/questions/3768522/missing-msvcr100-dll

Use static linking.
In the SQLite.Interop Visual Studio project. Go to this Properties setting: Project -> Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library  and change the value to Multi-threaded (/MT). (The current source code (1.0.71.0) has Multi-threaded DLL (/MD) which causes the dll to rely on MSVCR100.dll and the DLLImport (and LoadLibary()) to fail when users do not have it).

I believe static linking should be changed so it is the default for SQLite.Interop.dll. Thank you for your work on this project.

<hr /><i>anonymous added on 2011-04-29 14:52:39 UTC:</i><br />
Ran vcredist_x86. Test.exe still not working.  
Searched c:\windows\system32 and found msvcr100_clr0400.dll.
Copied that to same directory as Sqlite.Interop.dll. Test.exe still not working.
Renamed msvcr100_clr0400.dll to msvcr100.dll.  NOW IT WORKS!

Please static link.  This is too painful.

<hr /><i>anonymous added on 2011-05-04 11:50:38 UTC:</i><br />
I have downloaded and installed both x86 and x64 versions of 1.0.72.0 and have the same error on all. 

This is still a problem even if all of the dll's are in the project folder (including the msvcr100.dll)

I am running XP x64 using VS2008, the application is set to build for x86 only and the dll's I have copied are the x86 version (although the x64 version does the same)

<hr /><i>anonymous claiming to be Bastien added on 2011-05-06 08:44:15 UTC:</i><br />
Not sure that is this is related to the original bug, but I stumbled upon the same problem that the anonymous user at 2011-05-04 11:50:38 UTC posted. 

That is to say an x86 built app running on a x64 machine cannot use the x86 release of the 1.0.72.0 binary release. By "x86 built app" I mean the .NET application was aimed at an x86 architecture in the build options of the Visual Studio project.

It seems to me (although I actually have no clue about the involved process) that the interop DLL does not follow the rules of running in 32 bits when the process which uses it specifically runs into this mode (which is denoted in the Windows task manager by the "*32" appended to the process name). Replacing the x86 interop DLL by the x64 version does not work either in this situation.


<hr /><i>anonymous claiming to be Matt added on 2011-05-06 18:32:45 UTC:</i><br />
I too was getting this message "Unable to load DLL "SQLite.Interop.DLL". HRESULT 0x8007007E" I had originally installed using the GAC option. I had to un-install then reboot. I then re-installed without using the GAC option. I rebooted after the re-install and the issue went away.

<hr /><i>anonymous added on 2011-06-10 10:14:20 UTC:</i><br />
Please fix the static linking msvcr100.dll problem. I spent hours trying to figure out why a dll which WAS in the directory reported it could not be found! 

The whole point of using SQLite is the lack of dependencies...

<hr /><i>anonymous claiming to be anonymous SFA added on 2011-06-16 07:48:05 UTC:</i><br />
Yeah, this problem has been driving me nuts on and off for days.  The documentation that comes with the:
sqlite-dotnet-x86-1007300.exe and
sqlite-dotnet-x64-1007300.exe 
installers states the following about distribution:

-- Quote --
Distributing the Binaries (Desktop)
System.Data.SQLite.DLL is a mixed assembly signed with a strong name in case you want to add it to the Global Assembly Cache (GAC). This is the only DLL required to be redistributed with your SQLite.NET application(s).  It comes in 3 flavors: Win32, Itanium and x64 (AMD64).

Distributing the Binaries (Compact Framework)
System.Data.SQLite.DLL and SQLite.Interop.XXX.DLL must be deployed on the Compact Framework.  The XXX is the build number of the System.Data.SQLite library (e.g. "059").  SQLite.Interop.XXX is a fully native assembly compiled for the ARM processor, and System.Data.SQLite is the fully-managed Compact Framework assembly.
-- End Quote --

At a minimum, this should be updated to state the actual dependancies for distribution.  Note that for desktop it says that the System.Data.SQLite.DLL is all that's required. If not statically linked, msvcr100.dll and any others should also be included.  This would have saved me and all on this post grief.

<hr /><i>anonymous added on 2011-06-18 07:16:33 UTC:</i><br />
So for my development environment I include SQLite.Interop.DLL in my bin directory along with System.Data.SQLite.dll, and that works fine.

Problem here is that when I deployed all that on an XP machine, it fails miserably; even though both dll's are present. In any case, I'm back to 1.0.66.0.

<hr /><i>anonymous added on 2011-06-27 10:34:34 UTC:</i><br />
I have the same problem with 1.0.73, I also have to back to 1.0.66

------------------------------------------------------------------
So for my development environment I include SQLite.Interop.DLL in my bin directory along with System.Data.SQLite.dll, and that works fine.
 
Problem here is that when I deployed all that on an XP machine, it fails miserably; even though both dll's are present. In any case, I'm back to 1.0.66.0.


<hr /><i>mistachkin added on 2011-07-02 08:52:45 UTC:</i><br />
This issue will be 'fixed' in the next release by having bundled binary and setup packages that contain the mixed-mode assembly (i.e. the one that can be GAC'd).

However, the mixed-mode assembly (and the native interop library for non-bundled packages) will still rely on whichever version of the VC++ runtime it was compiled against.

Static linking is a very bad idea.  It makes it very hard to maintain, update, and secure the VC++ runtime itself.