SQLite Forum

SQLite.Interop.dll in different folder than expected?

SQLite.Interop.dll in different folder than expected?

(1) By Florian (Flohack) on 2024-04-23 13:05:20 [source]

Hi there, we are switching from a .net framework 48 build to net8.0 - which leads to having the SQLite.Interop.dll suddenly in the runtimes/xyz/native folder instead of x64 or x86 folders as before.

I would expect that the netstandard managed DLL will search for it in the new place, which does not seem to be the case - what I am doing wrong here?

I appreciate the move towards a standardized folder for such DLLs, but would be fine with shipping it also from the old folder structure. But currently it seems to be inconsistent.

Thanks BR Florian

(2) By Florian (Flohack) on 2024-04-23 13:49:54 in reply to 1 [link] [source]

FYI the new paths are runtimes\win-x86\native and win-x64 respectively, and the nuget package is pushing the interop there...

(3) By Florian (Flohack) on 2024-04-26 19:05:37 in reply to 1 [link] [source]

Hmm my band aid is now to copy the files in the CI pipeline from runtimes folders to the working location in x86 and x64 subfolders. But this is really not what it should be - can someone from the System.Data.SQLite team have a look at this?

(4) By Chris Locke (chrisjlocke1) on 2024-04-26 22:22:05 in reply to 1 [link] [source]

This is more a Nuget issue than anything else.

Rather than use Nuget, you can simply download the three DLLs (where two of them are the same...) and put in the x86 and x64 directories in the same directory as your .exe file (exactly as you did with .net 4.8 applications).

I've written .net 8 applications using this method with no issues.

(5) By Florian (Flohack) on 2024-04-26 22:35:45 in reply to 4 [link] [source]


yes sure I can do that. But I would rather not like to check in the dlls into Git for that matter, as we need repeatable builds in all release branches (mainly for patching).

I guess it would be possible to add another search path for that DLL, and be compatible with that runtimes folder idea. Because now finally that seems to be a standard for unmanaged libs, and that would clean up install folders quite a lot.

(6) By Florian (Flohack) on 2024-06-07 11:08:35 in reply to 4 [link] [source]

mistachkin do you think you can add these paths additionally when trying to load the Interop?

(7.3) By mistachkin on 2024-06-07 22:07:47 edited from 7.2 in reply to 6 [link] [source]

I will look a deeper into this issue this weekend.

EDIT #1: What happens if you set the following environment
         variable as follows?


EDIT #2: I've made preliminary changes on trunk to support
         automatically using the NuGet runtime identifiers
         to help locate the interop assembly, see:


(8) By Florian (Flohack) on 2024-06-10 08:37:31 in reply to 7.3 [link] [source]


I can confirm that setting the env variable fixes the issue. Thanks already. Of course I also would look forward to having this automatically resolved ;)

BR Florian

(9) By mistachkin on 2024-06-10 14:35:35 in reply to 8 [link] [source]

Thanks for the update.