Possible bug: Unable to find an entry point
(1) By anonymous on 2021-11-23 16:45:24 [link]
Hardware: Raspberry Pi 3 B+ OS: Debian Bullseye ARMv8 (64 bit) from the DietPi org libSQLite.Interop.dll compiled on above using sqlite-netFx-full-source-188.8.131.52 When running a .net 6 (core) app using System.Data.SQLite.Core 184.108.40.206 the following error is encountered on start: Unable to find an entry point named 'SIa069da76968b7553' in shared library 'SQLite.Interop.dll' When running the same app but with System.Data.SQLite.Core 1.0.115 (previous version) no error is encountered and the app functions normally. It’s unclear to me if this is a bug in 220.127.116.11 or if I’m doing something incorrect. Just throwing it out there in case it is a bug. Thanks.
(2) By Larry Brasfield (larrybr) on 2021-11-23 21:08:24 in reply to 1 [link]
> ... the following error is encountered on start: Unable to find an entry point named 'SIa069da76968b7553' in shared library 'SQLite.Interop.dll' I am highly skeptical that a name like that is supposed to be exported by that DLL. I've seen many name decoration schemes, but never one that appears to encode a 64-bit number with a prefix. And all the names exported by SQLite.Interop.dll for x86 and amd64 platforms are more ordinary, semi-meaningful-to-humans identifiers. Do you have any reason, beyond this error message, to believe that the System.Data.SQLite.Core library is, in fact, linked (albeit dynamically) to such an entry point?
(4) By anonymous on 2021-11-24 01:35:58 in reply to 2 [link]
I agree, it seemed quite unusual to me too. But that was the message verbatim. I have no other reason nor evidence. And admittedly I am in a litter over my head here. All I know is the same steps taken for two very close versions resulted in one working and one not. The possibility exists that I was just getting lucky with having one working as the following post might suggest. Thanks.
(3) By mistachkin on 2021-11-23 23:09:35 in reply to 1
The precompiled managed assemblies within the official NuGet packages are only intended to be used with the interop assemblies also from those NuGet packages.
(5) By anonymous on 2021-11-24 01:39:10 in reply to 3 [link]
Ah. That is good to know. Thank you!
(6) By webprofusion on 2021-12-20 03:27:33 in reply to 3 [link]
Hi, Further to this I can confirm that when upgrading from System.Data.SQLite.Core 18.104.22.168 to 22.214.171.124 and distributing our application to users that the users are frequently encountering the following error (not universally): ``` System.EntryPointNotFoundException: Unable to find an entry point named 'SIfcfad09d1b0a60ec' in DLL 'SQLite.Interop.dll'.\r\n at System.Data.SQLite.UnsafeNativeMethods.sqlite3_open_interop(Byte utf8Filename, Byte vfsName, SQLiteOpenFlagsEnum flags, Int32 extFuncs, IntPtr& db)\r\n at System.Data.SQLite.SQLite3.Open(String strFilename, String vfsName, SQLiteConnectionFlags connectionFlags, SQLiteOpenFlagsEnum openFlags, Int32 maxPoolSize, Boolean usePool)\r\n at System.Data.SQLite.SQLiteConnection.Open()\r\n at System.Data.Common.DbConnection.OpenAsync(CancellationToken cancellationToken)\ ``` We have been distributing this app with SQLite for years, generally following the latest System.Data.SQLite.Core My (unsubstantiated) theory is there could be a particular brand of Anti-Virus that's somehow interfering with the assembly load, or certain users have older SQLite.Interop.dll installed in the GAC and for some reason it's picking that up. I can confirm `SIfcfad09d1b0a60ec` is the SQLite.Interop.dll export of sqlite3_open_interop in 126.96.36.199 ``` [DllImport("SQLite.Interop.dll", EntryPoint = "SIfcfad09d1b0a60ec")] internal static extern SQLiteErrorCode sqlite3_open_interop( byte utf8Filename, byte vfsName, SQLiteOpenFlagsEnum flags, int extFuncs, ref IntPtr db); ```
(7) By tsuckow on 2022-03-06 04:37:44 in reply to 6 [link]
When building from the source zip, I don't get a compatible library. This must mean the nuget packages are built from a different set of source... Makes it rather difficult to support other platforms. Guess I'll just have to go back to 188.8.131.52 for freebsd
(8) By cguardia on 2022-04-13 01:53:36 in reply to 7 [link]
Same error here. Any update?
(9) By anonymous on 2022-04-22 22:04:36 in reply to 8 [link]
(10) By mistachkin on 2022-04-23 17:11:37 in reply to 9 [link]
Per my previous reply (see #3 above), this is by design.
(11) By anonymous on 2022-04-29 15:09:06 in reply to 10 [link]
for me, these are my test results: * v184.108.40.206 seems to work without exception * v220.127.116.11 runs into this exception so, the System.EntryPointNotFoundException at "SQLite.Interop.dll" might be introduced with some of last changes?
(12) By Paul Smith (PaulSmith) on 2022-05-01 07:09:45 in reply to 11 [link]
I had the same problem, so I uninstalled v18.104.22.168, and installed 22.214.171.124. Now I get this exception: System.IO.FileLoadException HResult=0x80131040 Message=Could not load file or assembly 'System.Data.SQLite, Version=126.96.36.199, Culture=neutral, PublicKeyToken=db937bc2d44ff139' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) I'd be grateful for any help with this. Thanks, paul
(13) By anonymous on 2022-06-01 08:37:39 in reply to 12 [link]
This simply means that the newer version i still referenced somewhere in your code
(14) By anonymous on 2022-06-13 11:29:10 in reply to 6 [link]
I don't understand why these SQLite.Interop.dll builds now use "encoded" entry point names. Just use plain english e.g. sqlite3_open_v2 or whatever. The newer versions which use these encoded entry points means the DLLs become useless for any use-cases outside of the "official" System.Data.Sqlite assembly. There are more use-cases for the SQLite.Interop.dll files than the maintainers perhaps realised.