... 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?

Hi,

Further to this I can confirm that when upgrading from System.Data.SQLite.Core 1.0.114.3 to 1.0.115.5 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 1.0.115.5

 [DllImport("SQLite.Interop.dll", EntryPoint = "SIfcfad09d1b0a60ec")]
    internal static extern SQLiteErrorCode sqlite3_open_interop(
      byte[] utf8Filename,
      byte[] vfsName,
      SQLiteOpenFlagsEnum flags,
      int extFuncs,
      ref IntPtr db);

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 1.0.114.3 for freebsd

Same error here. Any update?

Seconded

Per my previous reply (see #3 above), this is by design.

for me, these are my test results:

• v1.0.115.0 seems to work without exception
• v1.0.115.5 runs into this exception

so, the System.EntryPointNotFoundException at "SQLite.Interop.dll" might be introduced with some of last changes?

I had the same problem, so I uninstalled v1.0.115.5, and installed 1.0.115.0. Now I get this exception:

System.IO.FileLoadException HResult=0x80131040 Message=Could not load file or assembly 'System.Data.SQLite, Version=1.0.115.5, 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

This simply means that the newer version i still referenced somewhere in your code

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.

We too are desperate to see this fixed. Surely this is a backwards compatibly bug / oversight and not intentional, right?

I've spent much of a morning trying to guess the mangled name of sqlite3_create_window_function. Looking at the code it looks like it should be exported cleanly, but clearly it is not.

If you compare:

dumpbin /exports SQLite.Interop.dll

(on a Win64 machine) between 1.0.113.1 and 1.0.116.0 (both from the official nugets)

1.0.113.1 (perfect!)

Dump of file SQLite.Interop.dll

File Type: DLL

Section contains the following exports for SQLite.Interop.dll

00000000 characteristics
5ED282B6 time date stamp Sat May 30 16:58:46 2020
    0.00 version
       1 ordinal base
     387 number of functions
     387 number of names

ordinal hint RVA      name

      1    0 000380D0 _interop_compileoption_get@4
      2    1 000380F0 _interop_compileoption_used@4
      3    2 00038040 _interop_libversion@0
      4    3 00038030 _interop_sourceid@0
      9    4 000378E0 _sqlite3_backup_finish_interop@4
     17    5 00037D00 _sqlite3_bind_double_interop@12
     20    6 00037CC0 _sqlite3_bind_int64_interop@12
     25    7 00037C50 _sqlite3_bind_parameter_name_interop@12
     35    8 00037880 _sqlite3_blob_close_interop@4
     44    9 00037F10 _sqlite3_changes_interop@4
     47    A 00038050 _sqlite3_close_interop@4
     57    B 000373B0 _sqlite3_column_database_name16_interop@12
     58    C 00037410 _sqlite3_column_database_name_interop@12
     61    D 00037AF0 _sqlite3_column_decltype16_interop@12

... 106 7F 00088820 sqlite3_create_module_v2 107 80 0006C1F0 sqlite3_create_window_function (THIS IS WHAT I NEED!) 109 81 000D3B10 sqlite3_data_count ... 386 181 00042380 sqlite3session_patchset_strm 387 182 00043B80 sqlite3session_table_filter

Summary

    3000 .data
    1000 .gfids
   27000 .rdata
    8000 .reloc
    1000 .rsrc
  107000 .text

1.0.116.0 (broken)

Dump of file SQLite.Interop.dll

File Type: DLL

Section contains the following exports for SQLite.Interop.dll

00000000 characteristics
62979CAB time date stamp Wed Jun  1 18:06:51 2022
    0.00 version
       1 ordinal base
     206 number of functions
     206 number of names

ordinal hint RVA      name

      1    0 00057EA0 SI02815e94e2c315f7
      2    1 000586A0 SI039413da2b10b773
      3    2 00090410 SI054e3c8468772b2b
      4    3 001500B0 SI0628e029b7e108db
      5    4 001197F0 SI077534168313d3ed
      6    5 0004A300 SI0938f783b19237a0
      7    6 00053990 SI0a886fd4c720116f
      8    7 0011AD00 SI0bdc6d0c384d2e10
      9    8 000457E0 SI0ce1fad4c4f4a7fb
     10    9 00119F40 SI0cff507887d45bcd
     11    A 000580D0 SI0d6b1c4a8f9f99d4
     12    B 0008E370 SI0da8b85fb82501d5

.. 194 C1 00042CC0 SIf7e752fd3d0936c7 195 C2 0011A610 SIfc766c3d655f3fe2 196 C3 000453B0 SIfd60417394c54f67 197 C4 000F1FD0 SIfdd143ea824fb4f0 198 C5 0011BE60 SIff65f01991d44537 199 C6 00018DC0 sqlite3_cryptoapi_init 200 C7 00026870 sqlite3_fts5_init 201 C8 00026880 sqlite3_fts_init 202 C9 0001DFC0 sqlite3_percentile_init 203 CA 0001C4B0 sqlite3_regexp_init 204 CB 00019FA0 sqlite3_sha_init 205 CC 000193C0 sqlite3_totype_init 206 CD 00042C20 sqlite3_vtshim_init

Summary

    7000 .data
    1000 .gfids
   12000 .pdata
   43000 .rdata
    2000 .reloc
    1000 .rsrc
  154000 .text

That somewhat misses the point. We are using them from the managed assemblies, but happened to have added support for custom aggregate-window functions

so need the following to be callable

    [DllImport("SQLite.Interop.dll"]
    private static extern SQLiteErrorCode sqlite3_create_window_function(
        IntPtr db, byte[] strName, int nArgs, int nType, IntPtr pvUser,
        SQLiteCallback fStep, SQLiteFinalCallback fFinal, SQLiteFinalCallback fValue, SQLiteCallback fInverse, SQLiteDestroyCallback fDestroy);

to work... just as it was in older versions like 1.0.113.1

Joe has stated a true fact which is relevant to your "need". What you need to do is ensure that the correct DLL is loaded. This will necessitate more than merely naming "SQLite.Interop.dll" in the attribute. When a DLL to be loaded is specified without an absolute path, it is loaded according to a set of rules which you can lookup and exploit to solve your problem. First among those rules is that if the named DLL can be found in the same directory as the .exe which began the process, that will be loaded. (This is called "side-by-side" loading.)

What will not solve your problem is noisily hoping/wishing that what once happened to work for you will continue to work for you. If you were not taking care to get the correct DLL loaded, it was only an accident that one was found and loaded which happened to work. Taking such care is your job.

(Added via edit:) Taking care to ensure the correct DLL is loaded is established good practice even if somebody obviates your need to explicitly load a DLL or name mangling is done differently. The reason that side-by-side loading was added to the DLL locating algorithm was that problems such as are evident in this thread had proved to be very troublesome using the previous DLL loading rules.

By all means, that would be great! I spent a fair day or two building that functionality (always tricky to toenail things in like that) - and would love it to be core

Still I really can't understand why you would expose mangled names, when you used to support readable ones.

I call that a backward compatibility break, and limits how people can extend the great work of this library (as we have done).

In 1.0.117.0 maybe? :)

Yes, that is the plan.

Per #24 (below):

The feature is now present on the trunk in the System.Data.SQLite repository.

Could you please test it out and let me know of any problems you encounter?

Thank you for the answer. I see you reference this in emphatic manner right down the list of conversations. From my point of view, I'm a newbie to things INTEROP like and have absolutely no idea what your reply means. So, just as a matter of info - please consider adding to this reply a section that starts "For those who are in the dark or absolute newbies...this is how you go about getting those interop assemblies FROM THOSE NUGET PACKAGES:" I would greatly appreciate such a basic, down to the children, kind of answer instead of a repeated curt reference to the above. There are those of us who have to occasionally run into things we are totally clueless about and we will probably never touch again in our lives but just have to make it work at that moment because our jobs demand it.

What OS are you using, and what development package (software) are you using to use SQLite? You mention NuGet packages, so have you downloaded those? What have you tried, what has worked, and what are you struggling with?

Thanks for the response. I'm using Visual Studio 2019 on Windows 10 on Intel architecture and one of the User Controls forces a need for ANY CPU - otherwise it cannot be used if a specific CPU architecture is selected.

I am currently using Sqlite version 1.0.115 and I have Sqlite.Interop.dll in an x32 and in an x64 directory and it works.

If I try to update to the latest version of System.Data.Sqlite using Nuget ( since that is what is currently installed) I get the dreaded cannot find dll or whatever message ( long time since I looked at it ) - meaning the program is running in either 32bit or 64 bit mode and cannot find the other architecture of sqlite.interop.dll. Please tell me what exactly I should do to make it work. Thanks.

I just pulled the latest 1.0.117 for my Visual Studio 2022 project via nuget and I am running into the same issue.

"System.EntryPointNotFoundException: 'Entry point "SI17c3a78ecf9eff4c" not found in DLL "SQLite.Interop.dll".

I have no clue, why this not working anymore. We are using SQlite for years now and the call in C# has not change for years.

try { using (this.Connection = new SQLiteConnection("Data Source=:memory:;Version=3;New=True;")) { this.Connection.Open(); this.Connection.Update += Connection_Update; } } catch (SQLiteException ex) { throw new AFException(ex); } catch (EntryPointNotFoundException ex) { throw new AFException(ex); }

Any hint on how to fix this is much appreciated. Searching for a solution for hours now.

Kindest Christian

Rather than use Nuget, have you downloaded the 3 DLLs from system.data.sqlite.org? You may need to download the 32-bit and 64-bit versions, then put them in the right folders, but its not that complicated, and the download page has instructions.

Thanks for your reply. I solved it, but the issue was a different one.

Thanks anyway. Christian

how did you resolve this? I am running VS 2022 with System.Data.SQLite v 1.0.117, System.Data.SQLite.Core v 1.0.117, SQLite.Interop.dll v 1.0.103 and the program runs fine in VS but when I create the installer and install on my PC, I get the same error.

Why is this the case?