System.Data.SQLite

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