|22:10||• Closed ticket [54e52d4c6f]: Unable to load DLL 'SQLite.Interop.DLL' ... plus 1 other change artifact: 5ad975972c user: mistachkin|
|12:25||• Ticket [54e52d4c6f]: 1 change artifact: 1c6cea7c1c user: mistachkin|
|12:19||• Ticket [54e52d4c6f]: 1 change artifact: ba389de9de user: anonymous|
|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|
|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|
|11:30||• Ticket [54e52d4c6f]: 1 change artifact: d508838481 user: anonymous|
|09:21||• Ticket [54e52d4c6f]: 1 change artifact: 33031fb5b7 user: anonymous|
|08:04||• Closed ticket [54e52d4c6f]. artifact: ddce2af0b3 user: mistachkin|
|08:52||• Ticket [54e52d4c6f]: 3 changes artifact: 881d6b2912 user: mistachkin|
|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|
|10:34||• Ticket [54e52d4c6f] Unable to load DLL 'SQLite.Interop.DLL' ... status still Open with 2 other changes artifact: 9645c1e71e user: anonymous|
|07:16||• Ticket [54e52d4c6f]: 1 change artifact: 8f5250111f user: anonymous|
|07:48||• Ticket [54e52d4c6f]: 1 change artifact: 584de3fc5d user: anonymous|
|10:14||• Ticket [54e52d4c6f]: 1 change artifact: 5ae4d48d29 user: anonymous|
|18:32||• Ticket [54e52d4c6f]: 1 change artifact: 2042f08ab5 user: anonymous|
|08:44||• Ticket [54e52d4c6f]: 1 change artifact: a3d66df449 user: anonymous|
|11:50||• Ticket [54e52d4c6f]: 2 changes artifact: 130abefa60 user: anonymous|
|14:52||• Ticket [54e52d4c6f]: 1 change artifact: eebdb3fbc2 user: anonymous|
|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|
|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|
|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|
|11:00||• Ticket [54e52d4c6f]: 1 change artifact: f4956750a7 user: anonymous|
|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|
|17:36||• Review ticket [54e52d4c6f]. artifact: 2915969005 user: shane|
|21:13||• Ticket [54e52d4c6f]: 3 changes artifact: 78bc4df0f7 user: anonymous|
|21:12||• New ticket [54e52d4c6f]. artifact: 851ac7e775 user: anonymous|
|Title:||Unable to load DLL 'SQLite.Interop.DLL' ...|
|Last Modified:||2011-07-24 22:10:38|
|Version Found In:||126.96.36.199|
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:
anonymous added on 2011-04-16 05:24:01 UTC:
anonymous added on 2011-04-16 05:32:36 UTC:
This issue looks an installation bug (if the "Install to GAC" option is checked).
anonymous added on 2011-04-16 23:07:08 UTC:
anonymous added on 2011-04-23 11:00:59 UTC:
[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()
GAC Version Location --- ------- -------- True v2.0.50727 C:\Windows\assembly\GAC_MSIL\System.Data.SQLite\188.8.131.52__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:
anonymous added on 2011-04-25 15:48:27 UTC:
anonymous added on 2011-04-25 15:51:29 UTC:
anonymous added on 2011-04-25 18:25:43 UTC:
anonymous added on 2011-04-25 19:39:37 UTC:
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:
shane added on 2011-04-27 14:17:54 UTC:
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:
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 ?
anonymous added on 2011-04-27 20:18:17 UTC:
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..
anonymous claiming to be Helga added on 2011-04-28 13:14:27 UTC:
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:
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:
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 184.108.40.206 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 (220.127.116.11) 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:
Please static link. This is too painful.
anonymous added on 2011-05-04 11:50:38 UTC:
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:
That is to say an x86 built app running on a x64 machine cannot use the x86 release of the 18.104.22.168 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:
anonymous added on 2011-06-10 10:14:20 UTC:
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:
-- 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:
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 22.214.171.124.
anonymous added on 2011-06-27 10:34:34 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 126.96.36.199.
mistachkin added on 2011-07-02 08:52:45 UTC:
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:
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:
anonymous claiming to be Govert van Drimmelen added on 2011-07-06 10:00:07 UTC:
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.
mistachkin added on 2011-07-06 17:33:32 UTC:
anonymous claiming to be Govert van Drimmelen added on 2011-07-06 21:53:01 UTC:
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.
mistachkin added on 2011-07-07 01:31:01 UTC:
mistachkin added on 2011-07-07 01:48:05 UTC:
The 188.8.131.52 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:
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:
mistachkin added on 2011-07-24 22:10:38 UTC: