2.05 breaks with .NET Framework / AnyCPU

[jonreis]

Full Exception: System.DllNotFoundException: 'Unable to load DLL 'e_sqlcipher': The specified module could not be found. (Exception from HRESULT: 0x8007007E)'

Platform .NET 4.8 OS: Windows 10

The only change was upgrading from nuget package SQLitePCLRaw.bundle_e_sqlcipher 2.0.4 to 2.0.5.

Exception is thrown when: SQLitePCL.Batteries_V2.Init(); is called. For some reason the load library code is not finding the dll under runtimes\win-x64\native\e_sqlcipher.dll

[ericsink]

I'm guessing that you are building with AnyCPU? For diagnostic purposes, could you try building for x64 and see if the problem persists?

[jonreis]

Hello Eric, yes you are correct. If I set the platform target to x64 it works properly. It looks like the folder runtimes is still created but the e_cipher.dll is copied to the main directory which is where I am assuming it is now being loaded from.

[ericsink]

OK, this appears to be a consequence of my fix for #389.

In a nutshell, as I understand things, nowadays the recommended way of building a .NET Framework exe which needs native code assets is to use RuntimeIdentifier in the csproj. My previous approach was incompatible with that, so I fixed it, but in the process, AnyCPU broke.

I'm honestly not sure if AnyCPU is considered a supported thing anymore, but I'm interested in finding a way to make all these cases work.

[jonreis]

Thanks for taking a look at it Eric. I will take a look to see if my installer can copy the correct version of e_cipher.dll into the bin directory based on the platform. AnyCpu is nice for me right now as I can have a single installer for both x86 and x64, though I cannot see supporting x86 much longer.

[DannyBoyk]

Just ran into this myself. In our case, we went from SQLitePCLRAW.bundle_e_sqlcipher v2.0.1 to v2.0.6. We have only been using AnyCPU up till this point. We build for net461 and netcoreapp2.1 at the moment. We run unit tests for both builds. The netcoreapp2.1 tests run fine, but the net461 unit tests fail with the error seen above (except for e_sqlcipher.dll, not sqlite). If I add a new x64 solution platform, it still fails.

Observations for v2.0.1:

• When I build for AnyCPU, the e_sqlcipher.dll is placed directly under bin\Release\net461
• When I build for x64, the e_sqlcipher.dll is placed under bin\x64\Release\net461\runtimes\win-x64\native

These both pass unit tests for net461 and netcoreapp2.1.

Observations for v2.0.6:

• When I build for AnyCPU, the e_sqlcipher.dll is placed directly under bin\Release\net461
• When I build for x64, the e_sqlcipher.dll is placed under bin\x64\Release\net461\

Only the netcoreapp2.1 unit tests pass for these builds.

Like @jonreis , we'd like to continue to use AnyCPU if we can. Any other thoughts as to a solution for this?

[DannyBoyk]

I didn't realize I was on a different branch that was still using v2.0.1 the first time I posted. I updated my post above to reflect my observations for v2.0.1 and v2.0.6. Even if I add a x64 platform for v2.0.6, the net461 build fails. The runtimes\win-x64 folder does not show up for x64 v2.0.6 builds.

[softlion]

Same issue. Same conclusion. I also have the same issue on an Android device (xamarin android10 / latest version).

[softlion]

Ty !

[ericsink]

@softlion Did it work?

I just noticed this got auto-closed and I did not intend to close it until confirming the fix, so reopen...

[softlion]

Was just saying thank you !!!! :)

[softlion]

@ericsink it worked on android but not on UWP.

[ericsink]

@softlion UWP problems would be a separate issue. This issue is about .NET Framework with AnyCPU.

[Alexx999]

@ericsink I can confirm that it's fixed - we have AnyCPU netframework solution, we used 2.04 and it worked fine. After updating to 2.06 (skipping 2.05), I got DllNotFound in Batteries_V2.Init() and with 2.0.7-pre20210929171745 it works fine again. As a suggestion: if you load the library explicitly in Batteries_V2 (using LoadLibrary) you'd be able to stick to the preferred way of doing the calls (DllImport all the way) with no issue. I was going to add that on my side but then decided to look around a bit and found this issue.

[sjlombardo]

Hi @ericsink do you think that a release of 2.0.7 would be available soon, or will it remain in pre-release for a while? We're preparing a new SQLCipher release now, and are wondering whether we should plan to target a dependency on 2.0.4 to work around this issue, or hold off for a little while for 2.0.7 to be released.

[ericsink]

@sjlombardo I could release 2.0.7 about any time. I was just keeping it pre to see if anything else urgent showed up to be included. Would tomorrow or Wednesday be okay for your schedule? I just need to do all my last-minute checks.

[sjlombardo]

@ericsink that would be amazing, thank you!

[ericsink]

Fixed in 2.0.7, now on nuget.org