SQLitePCL.raw: "Library e_sqlite3 not found" on net472, but works on netcoreapp3.1
Given the most trivial netstandard2.0 library that consumes SQLitePCLRaw.bundle_green 2.0.4, that is then brought in by a unit test project that targets both netcoreapp3.1 and net472, we see the net472 one uniquely fails with this error:
Library e_sqlite3 not found
Yet looking at the bin directory for each target, we see both net472 and netcoreapp3.1 has e_sqlite3 in the directory alongside the test assembly.
What do I need to do so that net472 can find the native binary?
Minimal repro: SqliteTest.zip
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 15 (8 by maintainers)
Commits related to this issue
- experimental change. switch all the bundles to use dllimport providers for net461 instead of the dynamic provider. remove the targets file from lib.e_sqlite3 and lib.e_sqlcipher. in the test projec... — committed to ericsink/SQLitePCL.raw by ericsink 3 years ago
- bring back the .targets file, with a tweak. I'm referring to the targets file that applies only to .NET Framework, and is used to copy the native sqlite binaries into position. I removed the targets... — committed to ericsink/SQLitePCL.raw by ericsink 3 years ago
- revert the experimental fix for #389 and try a different approach. .net framework now uses the dynamic provider again, but now the search possibilities includes WHERE_ADJACENT to catch the case where... — committed to ericsink/SQLitePCL.raw by ericsink 3 years ago
(Mostly content-free update)
So far I haven’t actually taken the time to think hard about this issue. That targets file (and pretty much anything else that applies to .NET Framework but not .NET Core) is an area of the code I try to avoid thinking about.
That said, here is what has been going through my brain:
Since I don’t like thinking about this targets file, I usually rely on advice from people at Microsoft to tell me if I got it right.
The current approach was designed with lots of input from people at Microsoft who seemed awfully smart. When that conversation ended, those people seemed happy with the result, so I haven’t touched the targets file since then.
Now you have arrived, and you are also a person at Microsoft who seems awfully smart, and you’re not happy.
Spock in Star Trek IV might wonder if this is a good time for a colorful metaphor.
That conversation with the previous round of awfully smart Microsofties was a long time ago. Maybe something changed?
It looks like I’m going to have to turn my brain on and actually think about this issue. But that’s not happening until 2021. 😉
Fixed in 2.0.5
pre-release 2.0.5-pre20210521085756 has been pushed up to nuget, including the change described in #419 to default to use dllimport on .NET Framework.
I finally got back to digging into this issue. This involved re-learning some of my own code which I hadn’t looked at in a while.
The suggestion above from @AArnott was to “allow your native loader to find the native binary next to the managed assembly” and add a condition to the targets file.
But I started wondering what benefit my native loader is actually providing. See #419
So, as part of my exploration, I have implemented a more heavy-handed approach wherein (for .NET Framework) I eliminate my native loader (going back to dllimport) and remove the targets file. After that, adding the RuntimeIdentifiers and RuntimeIdentifier props gets my test suite running again.
Unit test projects with .NET framework are always troublesome.
If you’re talking about xunit, try adding an xunit.runner.json file that contains: