efcore: [.Net Framework 4.8]Library e_sqlite3 not found
A .Net Framework 4.8 program referencing a .Net Standard 2.0 using EFCore.Sqlite 3.1 can’t simply run (on Any CPU/X64/X86) with an exception shown:
System.TypeInitializationException: The type initializer for ‘Microsoft.Data.Sqlite.SqliteConnection’ threw an exception. —> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.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)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Microsoft.Data.Sqlite.Utilities.BundleInitializer.Initialize()
at Microsoft.Data.Sqlite.SqliteConnection..cctor()
--- End of inner exception stack trace ---
at Microsoft.Data.Sqlite.SqliteConnection..ctor(String connectionString)
at Microsoft.EntityFrameworkCore.Sqlite.Storage.Internal.SqliteRelationalConnection.CreateDbConnection()
at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.get_DbConnection()
at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.Open(Boolean errorsExpected)
at Microsoft.EntityFrameworkCore.Sqlite.Storage.Internal.SqliteDatabaseCreator.Exists()
at Microsoft.EntityFrameworkCore.Migrations.HistoryRepository.Exists()
at Microsoft.EntityFrameworkCore.Migrations.Internal.Migrator.Migrate(String targetMigration)
at Test.Program.Main(String[] args) in E:\Edit\CS\WPF\Memo\Test\Program.cs:line 22
But the output folder does contain e_sqlite3.dll, which seems to be a bug.
To Reproduce
var connection = "DataSource=default.db";
var builder = new DbContextOptionsBuilder<Db>();
builder.UseSqlite(connection);
builder.EnableSensitiveDataLogging();
var options = builder.Options;
using (var db = new Db(options))
{
db.Database.Migrate(); //this line throws that exception
}
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 15
- Comments: 54 (12 by maintainers)
When Visual Studio is running the unit tests (xUnit), the net48 DLLs are copied to a
AppData\Local\Tempfolder and executed from there. The native DLLs are not copied. That leads to this error.I’ve created a hack to workaround the issue. It copies the
runtimesfolder from the Assembly.Location to Assembly.CodeBase folders. In my case, I only need this when running unit tests, so I’m fine with the ugliness of the hack. Ithttps://gist.github.com/FuncLun/fff2c63c7d37f4ff3d20f70e00bb241f
Another way to workaround this issue that doesn’t involve adding code in your test project is to disable xUnit test runner shadow copy. Here is how:
xunit.runner.jsonfile with the following contentHere’s how I did it on @MatthewKing’s sample code: https://github.com/0xced/Issue19396/commit/73d1504b2698b3db23309e40364b4e943fab315e
And once you know the solution, it becomes easier to find where it was already discussed. ¯_(ツ)_/¯
I’m getting this same error with .NET Framework 4.7.2. I am referencing a .Net Standard 2.0 class library on a WPF project targetting .NetFramework 4.7.2.
G’day @ajcvickers I’m not the original submitter of this issue, but I think I’m running in to the same thing - except on net472.
I’ve put together a very very simple project that reproduces the issue. Doesn’t even need EFCore, just Microsoft.Data.Sqlite is sufficient to reproduce the issue. https://github.com/MatthewKing/Issue19396
Unless I’m doing something wrong?
(Oh my, you’re still on packages.config. Switching to PackageReference is highly recommended.)
2.0.5-pre20210521085756 contains an experimental change to try to use the old DllImport approach to finding e_sqlite3.dll when on .NET Framework. I implemented this change in response to some feedback, but I’m still trying to figure out how to support people with it.
In principle, if you’re using that version of SQLitePCLRaw, e_sqlite3.dll should be found if it is in the main build output directory. And it needs to match the CPU you are building for.
The error message you provided above would seem to suggest that e_sqlite3.dll is being found but it is in the wrong CPU architecture.
As an experiment, try building for x64 and putting the x64 version of e_sqlite3.dll into the main build output directory.
Another thing I’ll mention is this little block of msbuild code:
Again, for 2.0.5-pre20210521085756, I have found this snippet to be important, but I’m building/testing with the dotnet CLI and SDK-style projects. If you’re using old-style csproj files, I’m not sure the RuntimeIdentifier stuff is helpful or needed.
@ericsink suggested a solution here: https://github.com/ericsink/SQLitePCL.raw/issues/485
For me it works when explicit reference a newer version
SQLitePCLRaw.bundle_e_sqlite3i think
v2.0.7fixes this.Also having this issue with an ASP.NET / IIS app. The code works fine in a console/Windows app, but fails with this same error when running within IIS.
I’ve got the same issue running on .NET Framework v4.8 and xUnit Test Runner for Visual Studio v2.4.1: https://github.com/dotnet/efcore/issues/19893
— ngm
I am using AnyCPU so that my build produces a single platform independent output folder (bin/) with various subfolders in bin/runtimes/ for the supported platforms (win-x86, win-x64, win-arm). Only at runtime, the process picks the proper native DLL for the platform that it currently runs on. All this works fine with 2.0.4.
2.0.5 seems to have lost the ability to select a DLL during runtime and instead depends on the build process to depoly a specific native DLL to bin/, which makes the whole build output platform specific.
I tried to add the XML snippet you mentioned to my .csproj file, but that does not seem to have any effect (on a .NET Framework 4.8 VS2019 IDE build). When I run a clean build with SQLitePCLRaw.lib.e_sqlite3 2.0.4 installed, the output folder will contain a runtimes/ subfolder with win-arm, win-x64, win-x86. However, it doesn’t contain a win-arm64 folder despite me adding win-arm64 to the <RuntimeIdentifiers> in the .csproj file. Neither is there DLL deployed directly to bin/e_sqlite.dll. A build with 2.0.5 won’t create any runtimes/ subfolder, neither will it copy a DLL to bin/e_sqlite.dll. If it copy the x64 native DLL there myself, the program works on a x64 machine. But I’d have to detect the current platform myself during runtime and copy the right DLL before I open a SQLite database file
In some scenarios I’ve had to decorate the testing class with requirement for the binaries like follows:
It’s fairly simple workaround that works for me.
Was having this issue when running a WPF app. I installed SQlitePCLRaw.bundle_e_sqlite3 v 2.0.4 and the error went away.
@FuncLun Thank you!
I was getting this in a .net 4.8 framework asp.net mvc site due to the shadow cache (It was copying it to C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\vs\c0b0bd77\359dbc76\assembly\dl3\1a57f6b2\002f8908_9690d501\SQLitePCLRaw.core.dll)
Unfortunately it was manifesting as a null exception which threw me off the trail for a while.
I’m getting this same error with .NET Framework 4.7.2. It is definitely a problem with the Visual Studio Test runner as identical code works fine when run as a regular application. I have added literally every sqlite package to the Test Project to no avail. Does anyone have any suggestions?