System.Data.SQLite
View Ticket
Not logged in
2011-07-24
22:10 Closed ticket [54e52d4c6f]: Unable to load DLL 'SQLite.Interop.DLL' ... plus 1 other change artifact: 5ad975972c user: mistachkin
2011-07-08
12:25 Ticket [54e52d4c6f]: 1 change artifact: 1c6cea7c1c user: mistachkin
12:19 Ticket [54e52d4c6f]: 1 change artifact: ba389de9de user: anonymous
2011-07-07
04:39 Ticket [c7c7b6f987] [DllNotFoundException: 无法加载 DLL“SQLite.Interop.DLL”: 找不到指定的模块 status still Closed with 2 other changes artifact: fdc7a36c49 user: mistachkin
04:38 Ticket [684b126a33] Downloaded package is debug build status still Closed with 2 other changes artifact: fcf15721b5 user: mistachkin
04:26 Ticket [54e52d4c6f] Unable to load DLL 'SQLite.Interop.DLL' ... status still Open with 2 other changes artifact: b509e98a84 user: mistachkin
01:48 Ticket [54e52d4c6f]: 1 change artifact: 7f21dfecc9 user: mistachkin
01:31 Open ticket [54e52d4c6f]. artifact: 8d4a35b3af user: mistachkin
01:31 Ticket [54e52d4c6f]: 1 change artifact: 0dcae23d32 user: mistachkin
2011-07-06
21:53 Ticket [54e52d4c6f]: 1 change artifact: 3cc697273b user: anonymous
17:33 Ticket [54e52d4c6f]: 1 change artifact: 353e0d0fea user: mistachkin
10:00 Ticket [54e52d4c6f]: 1 change artifact: 88e4f70ad6 user: anonymous
2011-07-05
11:30 Ticket [54e52d4c6f]: 1 change artifact: d508838481 user: anonymous
09:21 Ticket [54e52d4c6f]: 1 change artifact: 33031fb5b7 user: anonymous
2011-07-04
08:04 Closed ticket [54e52d4c6f]. artifact: ddce2af0b3 user: mistachkin
2011-07-02
08:52 Ticket [54e52d4c6f]: 3 changes artifact: 881d6b2912 user: mistachkin
2011-07-01
04:15 Closed ticket [684b126a33]: Downloaded package is debug build plus 3 other changes artifact: f88888bef4 user: mistachkin
04:13 Closed ticket [c7c7b6f987]: [DllNotFoundException: 无法加载 DLL“SQLite.Interop.DLL”: 找不到指定的模块 plus 2 other changes artifact: 1c783da765 user: mistachkin
2011-06-27
10:34 Ticket [54e52d4c6f] Unable to load DLL 'SQLite.Interop.DLL' ... status still Open with 2 other changes artifact: 9645c1e71e user: anonymous
2011-06-18
07:16 Ticket [54e52d4c6f]: 1 change artifact: 8f5250111f user: anonymous
2011-06-16
07:48 Ticket [54e52d4c6f]: 1 change artifact: 584de3fc5d user: anonymous
2011-06-10
10:14 Ticket [54e52d4c6f]: 1 change artifact: 5ae4d48d29 user: anonymous
2011-05-06
18:32 Ticket [54e52d4c6f]: 1 change artifact: 2042f08ab5 user: anonymous
08:44 Ticket [54e52d4c6f]: 1 change artifact: a3d66df449 user: anonymous
2011-05-04
11:50 Ticket [54e52d4c6f]: 2 changes artifact: 130abefa60 user: anonymous
2011-04-29
14:52 Ticket [54e52d4c6f]: 1 change artifact: eebdb3fbc2 user: anonymous
2011-04-28
21:17 Ticket [54e52d4c6f]: 2 changes artifact: 69abeaca6f user: anonymous
18:39 Ticket [54e52d4c6f]: 1 change artifact: f35f044f11 user: anonymous
13:14 Ticket [54e52d4c6f]: 1 change artifact: 3d697ab1c5 user: anonymous
2011-04-27
20:18 Ticket [54e52d4c6f]: 1 change artifact: 65e882ace1 user: anonymous
19:48 Ticket [54e52d4c6f]: 1 change artifact: 41811a1d95 user: anonymous
14:17 Ticket [54e52d4c6f]: 1 change artifact: 45820ece9e user: shane
00:42 Ticket [54e52d4c6f]: 2 changes artifact: 0a84e04af2 user: anonymous
2011-04-25
19:39 Ticket [54e52d4c6f]: 1 change artifact: 2727591ca4 user: anonymous
18:25 Ticket [54e52d4c6f]: 2 changes artifact: 2f603ea11c user: anonymous
15:51 Open ticket [54e52d4c6f]. artifact: 9113552d4a user: anonymous
15:48 Ticket [54e52d4c6f]: 1 change artifact: 7b59cbce57 user: anonymous
12:14 Ticket [54e52d4c6f]: 1 change artifact: 555fefa407 user: anonymous
2011-04-23
11:00 Ticket [54e52d4c6f]: 1 change artifact: f4956750a7 user: anonymous
2011-04-16
23:07 Closed ticket [54e52d4c6f]. artifact: 96c1865e72 user: anonymous
05:32 Ticket [54e52d4c6f]: 1 change artifact: a45b44a3cd user: anonymous
05:24 Ticket [54e52d4c6f]: 1 change artifact: e12aaebaba user: anonymous
2011-04-15
17:36 Review ticket [54e52d4c6f]. artifact: 2915969005 user: shane
2011-04-14
21:13 Ticket [54e52d4c6f]: 3 changes artifact: 78bc4df0f7 user: anonymous
21:12 New ticket [54e52d4c6f]. artifact: 851ac7e775 user: anonymous

Ticket Hash: 54e52d4c6f92083749d5796672d09d7dce56643c
Title: Unable to load DLL 'SQLite.Interop.DLL' ...
Status: Closed Type: Build_Problem
Severity: Critical Priority: Immediate
Subsystem: Build_Automation Resolution: Fixed
Last Modified: 2011-07-24 22:10:38
Version Found In: 1.0.73.0
Description:
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 ....

shane added on 2011-04-15 17:36:29 UTC:
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.


anonymous added on 2011-04-16 05:24:01 UTC:
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.


anonymous added on 2011-04-16 05:32:36 UTC:
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).


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


anonymous added on 2011-04-23 11:00:59 UTC:
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.


anonymous added on 2011-04-25 12:14:53 UTC:
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.


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


anonymous added on 2011-04-25 15:51:29 UTC:
Setting Status to "Open".


anonymous added on 2011-04-25 18:25:43 UTC:
Changed resolution to "Open".


anonymous added on 2011-04-25 19:39:37 UTC:
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.


anonymous added on 2011-04-27 00:42:02 UTC:
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..


shane added on 2011-04-27 14:17:54 UTC:
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?


anonymous added on 2011-04-27 19:48:20 UTC:
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


anonymous added on 2011-04-27 20:18:17 UTC:
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


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

I downloaded sqlite-dotnetsrc-1007100.zip 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 bin\test.exe 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!


anonymous added on 2011-04-28 18:39:41 UTC:
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.


anonymous added on 2011-04-28 21:17:50 UTC:
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.


anonymous added on 2011-04-29 14:52:39 UTC:
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.


anonymous added on 2011-05-04 11:50:38 UTC:
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)


anonymous claiming to be Bastien added on 2011-05-06 08:44:15 UTC:
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.


anonymous claiming to be Matt added on 2011-05-06 18:32:45 UTC:
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.


anonymous added on 2011-06-10 10:14:20 UTC:
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...


anonymous claiming to be anonymous SFA added on 2011-06-16 07:48:05 UTC:
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.


anonymous added on 2011-06-18 07:16:33 UTC:
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.


anonymous added on 2011-06-27 10:34:34 UTC:
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.


mistachkin added on 2011-07-02 08:52:45 UTC:
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.


anonymous added on 2011-07-05 09:21:01 UTC:
Thank you for taking on the task of building great .NET support for SQLite.

I'm hoping that the decisions in this thread can be reconsidered.

Having a dependency on the SP1 version of the MSVC runtime is a showstopper for me, and I think for many other users. One really important use case for SQLite on .NET is to have a single .dll (or a few) that can be xcopy-deployed, with only the .NET runtime as a dependency. This is what previous versions up to 1.0.66 gave us. By linking to the respective SP1 versions, an extra installation step is forced, which is often very inconvenient. And sometimes impossible to deploy, due to admin privilege issues or runtime model (say the .NET assembly is just an add-in for another program).

I understand the concern with static linking, though that would be much, much better than what we have now. The only other xcopy-deployable approach would be to copy the runtime libraries along with the app. This only works if the library is in the same directory as the executable, and means that the runtime will not be serviced by Windows updates anyway. So in practice that is no better than static linking.

Perhaps there could be a build that dynamically links against the version of the MSVC runtime that ships with the respective .NET version. You can control which version of the MSVC runtime is loaded by manually overriding the manifest that is embedded in the .dll. If you dynamically link to the released versions of each runtime .dll, that version can still be serviced for security updates etc., and the library will work out of the box.

-Govert van Drimmelen


anonymous added on 2011-07-05 11:30:52 UTC:
I could not say that better than Govert van Drimmelen did. Please, consider this kind of build, too, with VS runtime statically linked. As far as System.Data.SQLite is for community after all and the community or the reasonable part of it needs this kind of build then why not to take this fact into account? Please, do. Thank you for the great job!


anonymous claiming to be Govert van Drimmelen added on 2011-07-06 10:00:07 UTC:
To be clear:

While I think static linking would be better than the SP1 runtime dependency we have now, my preference would be for dynamic linking to the MSVC runtime version that ships with the respective .NET versions - this just requires the manifest embedded in the .dll to point to the right version.

-Govert


mistachkin added on 2011-07-06 17:33:32 UTC:
I will investigate modifying the embedded manifests to match the RTM versions of the respective VC++ runtimes.


anonymous claiming to be Govert van Drimmelen added on 2011-07-06 21:53:01 UTC:
Thank you very much for revisiting this!

I think it is a certainly worthwhile for the project to figure it out so that the library can always run on the RTM version of .NET, and can also be reliably rebuilt on the SP1 versions of Visual Studio.

I add some more information that could possibly help:

This is the closest I could see for a recipe on how to implement this: http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/.

It seems defining _CRT_ASSEMBLY_VERSION allow a different approach to explicitly setting up the manifest to embed. And _BIND_TO_CURRENT_VCLIBS_VERSION is another flag that affects the manifest and binding. There is more discussion here: http://groups.google.com/group/microsoft.public.win32.programmer.tools/tree/browse_frm/thread/16cae5f1305b05f5.

This StackOverflow question has a small discussion about doing this: http://stackoverflow.com/questions/5790226/using-version-4053-of-crt-md-instead-of-leatest-greatest-5592-in-dll-vs2005.

-Govert


mistachkin added on 2011-07-07 01:31:01 UTC:
Thanks. I found that information this morning in my research. Also, could you please test the .NET 4.0 (VC10 RTM) version of the DLL because apparently that runtime version does *NOT* require an embedded manifest for binding.


mistachkin added on 2011-07-07 01:48:05 UTC:

The 1.0.74.0 release DLLs of System.Data.SQLite have the following information in their manifests:

<dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"> </assemblyIdentity> </dependentAssembly> </dependency>

That *IS* the RTM version of the VC9 runtime; therefore, using the CRT binding #define's won't make any difference here.

So the question becomes, is there anything else to be done for this ticket?


anonymous claiming to be Govert van Drimmelen added on 2011-07-08 12:19:52 UTC:
OK - I've tried to figure out what's going in the MSVCR100 / .NET 4 case. I understand that my earlier advice was not useful - sorry that I didn't do more homework before.

1. Installing the RTM version of the Visual C++ runtime libraries works perfectly with System.Data.SQLite 1.0.74. So the SP1 version is not needed.

2. The version of the C runtime installed with the .NET 4 runtime is the RTM version of msvcr100, but has the name msvcr100_clr0400.dll. With a copy of this renamed to msvcr100.dll, either in System32 or next to the System.Data.SQLite.dll, everything seems to work.

3. It seems they've moved away from SxS deployment of the C runtime. So no more 'dependency' tag in the embedded manifest, and whatever the latest version is in System32 (or same directory as the .exe) will be loaded.

I've asked a question on StackOverflow about these changes: http://stackoverflow.com/questions/6623780/visual-c-2010-changes-to-msvc-runtime-deployment-no-more-sxs-with-manifest.

This all means for the .NET 4 version I can deploy System.Data.SQLite.dll and msvcr100.dll in the same directory, which was not possible with the previous version of the runtime. For me that sorts out all my problems and I can move to the current versions of System.Data.SQLite.dll.


mistachkin added on 2011-07-08 12:25:42 UTC:
Ok, so it sounds like everybody is happy at this point? If so, this ticket can be closed.


mistachkin added on 2011-07-24 22:10:38 UTC:
Closing...