e_sqlite3.dll DLLNotFound after upgrading from 2.1.11 to 3.0.2

[skyhawlk]

I am using SQLitePCLRaw nugets as dependencies to Microsoft.Data.Sqlite 9.0.5 in a dotnet framework 4.8 targeted app for x86, x64 and arm64 platforms (msbuild project).

I have upgraded SQLitePCLRaw (also SQLitePCLRaw.bundle_e_sqlite3) from version 2.1.11 to the recent v3.0.2,

After that I discovered that the app (EXE) no longer able to find e_sqlite3.dll native lib under the runtimes folders, which was working before the upgrade.

update: I have added SourceGear.sqlite3 3.0.2 as well (per the readme at https://github.com/ericsink/SQLitePCL.raw/blob/main/v3.md), but it also can not find the native dlls unless they are manually copied to the app output.

The runtime folders are copied by the nuget target (for dotnet framework 4.7.1) - so it seems that there is no DLLImport on the new bundle nuget (since we are on netstandard 2.0), or I'm missing something else?

[ericsink]

Hmm. Unfortunately, SQLitePCLRaw 3.0.x doesn't currently support that case. I'm a bit surprised anyone was able to use it successfully with 2.1.x.

I'll need to investigate what can be done here.

Do you get a build-time error about trying to use Any CPU?

[skyhawlk]

No. I have win-x86;win-x64; win-arm64 RID's in the csproj for Any CPU, which might explain why I don't get that error message.

[ericsink]

So you have something like this?

<RuntimeIdentifiers>win-x86;win-x64;win-arm64<RuntimeIdentifiers>

and in 2.1.x, were all three of those DLLs being copied into the build output? In subdirectories?

I'm trying to figure out if you were doing one "AnyCPU-style" build, where the managed code is built once and it decides at runtime which native library to load, because all three were present.

Or were you simply building your project for 3 different CPUs, each one getting its own build output directory?

[skyhawlk]

Yes- <RuntimeIdentifiers>win-x86;win-x64;win-arm64<RuntimeIdentifiers> For x64/x86 I'm doing one "AnyCPU" build. For win-arm64 - the AnyCPU config is targeted for ARM64 machine (different build pipeline). The 3 runtime folders are being copied by your nuget to the build output folder. Then I copy the runtime folder "as is" to the Program Files\<App>\Runtime\**. My guess is that in 2.1.x, the bundle was adding the folder to the DLL search path and the managed code just kept on trying all three dlls until one of them got loaded.

…

On Tue, Sep 16, 2025 at 5:06 PM Eric Sink ***@***.***> wrote: So you have something like this? <RuntimeIdentifiers>win-x86;win-x64;win-arm64<RuntimeIdentifiers> and in 2.1.x, were all three of those DLLs being copied into the build output? In subdirectories? I'm trying to figure out if you were doing one "AnyCPU-style" build, where the managed code is built once and it decides at runtime which native library to load, because all three were present. Or were you simply building your project for 3 different CPUs, each one getting its own build output directory? — Reply to this email directly, view it on GitHub <#647 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZ2PCWBRJKTCT7UC2EZD233TAKOVAVCNFSM6AAAAACGUR5G5SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINBRGY3DGOA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ericsink]

In 2.1.x, the .NET Framework configurations used a "dynamic" provider, but I changed this in 3.0.x to use regular DllImport, because it makes most cases work better. But not yours. :-(

[skyhawlk]

Is there anyway you could re-instate the code that was handling this for 3.X?

[ericsink]

Not easily, but yeah, that's what I plan to try and figure out.