sqlite-net
sqlite-net copied to clipboard
Error "Library e_sqlite3 not found" when creating new SQLiteConnection on .net 4.7.2
I created a new project "Console App (.NET Framework)" with VS 2019 (16.4.5) and added "sqlite-net-pcl 1.7.335". This code causes the error:
static void Main(string[] args)
{
try
{
var con = new SQLiteConnection(@"d:\temp\1.sqlite");
}
catch (Exception e)
{
Console.ForegroundColor = ConsoleColor.Red;
Console.WriteLine("{0}\n{1}", e.Message, e.InnerException);
Console.ResetColor();
}
Console.ReadKey();
}
After building the program there is no "e_sqlite3.dll" in the output folder. I copied it from the package folder of "sqlitepclraw.lib.e_sqlite3\2.0.3\runtimes" (tried with all win-versions), but the error still remains.
I think it is a problem with the referenced Package "SQLitePCLRaw.bundle_green". This should use "e_sqlite3" on all plattforms, except iOS. (from https://github.com/ericsink/SQLitePCL.raw) If I add "SQLitePCLRaw.bundle_e_sqlite3" which use "e_sqlite3" on all plattforms, it works. (SQLitePCLRaw.bundle_green doesnt create the folder "runtimes" and it's subdirs in the output folder, but SQLitePCLRaw.bundle_e_sqlite3 does)
Same issue here, but I only got the error after switching from debug to release mode. In debug mode, e_sqlite3.dll is not present in the output folder and it works. The file is not a .NET assembly and I haven't yet found out what kind of file it is.
The files are available in my debug output folder when it works:
If I change the platform target in release mode to X86 or X64, e_sqlite3.dll appears. If it's set to AnyCPU, the file does not get copied to the output folder.
I fixed it for now by switching to AnyCPU and sqlite-net 1.6.292.
Edit: I just found out that e_sqlite3.dll is just copied to X64 and X86 folders when I select AnyCPU, it doesn't disappear.
@brinkdinges I think e_sqlite3.dll is the native lib for the current platform (https://github.com/ericsink/SQLitePCL.raw)
Can't solve the problem in an asp.net web application with the workarounds listet above. I ended in removing all sqlite nugets and adding SQLite.cs to the project. Furthermore I extract the binary sqlite (with encryption) from .nuget\packages\sqlitepclraw.lib.sqlcipher.windows\1.1.11\runtimes\win-x64\native, renamed it to sqlite3.dll and copied it to the outputfolder.
Recently upgraded sqlite-net-pcl from 1.6.292 to 1.7.335 in VS2019 and have the exact same issue with my Winforms app (a VSTO Office Addin). Android and UWP apps are fine. e_sqlite3.dll is copied to the debug output directory (provided project build nominates x64 or x86) but is never found for loading. Was working OK in 1.6.292 but would like to stay with later version.
I encountered this problem about 5 months ago and because I could not find a solution, I used MS Access database in the application I developed.
Now I wanted to use sqlite in a Windows Forms (.Net.Framework) application but; this problem still seems unresolved. I've tried it with both sqlite-net-pcl and Microsoft.Data.Sqlite, unfortunately nothing has changed.
It works fine when I try it in both debug and release mode, but when I publish it or when I create an installation package with the setup project and install it on any computer, I get the "System.Exception: Library e_sqlite3 not found" error.
I tried all of the solutions suggested in Github, Stackoverflow and many other forums but failed.
I guess the problem is caused by this file. I tried manually copying the file (both 32 bit and 64 bit versions) to the folder where the application was installed and into the system32 folder, and it didn't work as expected :)
I feel like there is a very simple solution but we can't find it.
Attached is a quick sample I just created using sqlite-net and .NET Framework. To create this, I did the following steps:
- Whine and complain that anybody is using .NET Framework
- Open Visual Studio 2019 and create a console app for .NET Framework
- Add the nuget package sqlite-net-base
- Express shock and outrage that a current version of Visual Studio is capable of creating a packages.config file
- Convert the project to use PackageReference.
- Stop and watch the new episode of The Mandalorian. This is the way.
- Add the nuget package SQLitePCLRaw.bundle.e_sqlite3 version 2.0.4
- Add code to Main() to open a connection and print out the SQLite version.
- Run the project, watch it fail because I forgot to call SQLitePCL.Batteries.Init()
- Add the SQLitePCL.Batteries.Init() call to Main()
- Run the project, watch it print out 3.33.0
Attached is a quick sample I just created using sqlite-net and .NET Framework. To create this, I did the following steps:
- Whine and complain that anybody is using .NET Framework
- Open Visual Studio 2019 and create a console app for .NET Framework
- Add the nuget package sqlite-net-base
- Express shock and outrage that a current version of Visual Studio is capable of creating a packages.config file
- Convert the project to use PackageReference.
- Stop and watch the new episode of The Mandalorian. This is the way.
- Add the nuget package SQLitePCLRaw.bundle.e_sqlite3 version 2.0.4
- Add code to Main() to open a connection and print out the SQLite version.
- Run the project, watch it fail because I forgot to call SQLitePCL.Batteries.Init()
- Add the SQLitePCL.Batteries.Init() call to Main()
- Run the project, watch it print out 3.33.0
The sample application you sent works fine in debug mode. But when I add a setup project to the solution and install the application on the computer, I still encounter the same problem.
Ah, sorry, I missed the bit about the setup project.
That means your problem is quite different from the original issue here.
Also, it seems like the problem isn't necessarily related to SQLite-net or SQLitePCLRaw. I'm not familiar with whatever setup project/tool that is, but the SQLite stuff clearly works until the setup project gets involved. If it's dropping a file, perhaps there is a way to fix that by explicit inclusion or whatever.
I have a solution divided into application assemblies. DB assembly, models assembly.
The DB assembly references SQLite net PCL. When upgrading to version 1.7.335, prompt library E_ sqlite3 not found。
According to the results of stack overflow, the application assembly I restart also adds a reference to SQLite net PCL. The problem is solved.
But I don't need to access the database directly under the application program. So I don't understand why this problem can be solved like this?
Can you answer my question. thank.
Adding a reference to the application project is how the build system knows which platform to use for the native SQLite library.
I just retried updating SQLite-net again, now to version 1.8 since 1.7 gave me troubles, see my comment near the top. Any idea what I need to do to get e_sqlite3.dll to be copied to the output directory?
- I'm now only referencing the sqlite-net-pcl NuGet package, do I need to add more?
- I target .NET Framework 4.8
- The project uses the AnyCPU platform
- I don't see the file anywhere in the output directory or its subfolders
My stack trace: Exception: Library e_sqlite3 not found at SQLitePCL.NativeLibrary.Load(String libraryName, Assembly assy, Int32 flags) at SQLitePCL.Batteries_V2.MakeDynamic(String name, Int32 flags) at SQLitePCL.Batteries_V2.DoDynamic_cdecl(String name, Int32 flags) at SQLite.SQLiteConnection..cctor()
Does it need to use AnyCPU?
If you add a RuntimeIdentifier
property to your csproj, does that affect the problem?
Regarding AnyCPU: I don't know. I've always kept it at AnyCPU just to be sure. I'll look into it.
I added <RuntimeIdentifier>win10-x64</RuntimeIdentifier> to the project and noticed two effects so far:
- e_sqlite3.dll gets copied to the output directory, plus to a x64 and x86 subfolder.
- I cannot register my own plugin DLL with COM anymore. The stack trace mentions e_sqlite3.dll. It's not SQLite's fault probably, I may need to dig into what this custom register tool is doing. If I can't register, I can't run my plugin to test it.
Unexpected error: System.BadImageFormatException: Could not load file or assembly 'file:///C:\Users......\bin\Debug\net48\win10-x64\e_sqlite3.dll' or one of its dependencies. The module was expected to contain an assembly manifest. File name: 'file:///C:\Users......\bin\Debug\net48\win10-x64\e_sqlite3.dll' at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark) at System.Reflection.Assembly.LoadFrom(String assemblyFile) at x.PlugInIntegration.GetPlugIns(String pluginFullPath, Action`1 onFound) at x.PlugInIntegration.GetSolidPlugIns(String addinPath) at x.PlugInIntegration.ConfigurePlugIns(String addinPath, SolidAddIn solidAddIn) at x.SolidAddIn.ComRegister(Type t)
It kinda looks like something is noticing e_sqlite3.dll and assuming it is a plugin, a .NET assembly, when actually it is a native DLL.
It probably assumes it's a .NET assembly, indeed. I'll check that tool to see if I can propose a fix for that. Thanks 👍
My plugins run inside SolidWorks, which only runs on 64-bit versions of Windows 7 and 10. So targeting x64 should be possible.
I removed the RuntimeIdentifier and changed the target to x64 in all projects, I did not notice a difference in behavior, the sqlite dll does not get copied to the output.
@brinkdinges Do you by chance have a minimal reproduction project you could post?
Today I tried creating a .NET Framework project that uses AnyCPU so that I could reproduce this class of problems and experiment with fixes, but, the problem doesn't show up for me. Maybe I need to be using older versions of the tooling.