SQLitePCL.raw icon indicating copy to clipboard operation
SQLitePCL.raw copied to clipboard

Impossible to use SQLitePCLRaw.provider.dynamic_cdecl from .net framework library

Open professor-k opened this issue 2 years ago • 3 comments

We use third party native SQLite binaries in conjunction with SQLitePCLRaw.provider.dynamic_cdecl in application that runs both on .Net Framework 4.7.2 and .Net 6.0. SQLite3MultipleCiphers provides support for RC4 cipher used earlier in System.Data.SQLite, and so far it's the only way we found to migrate from System.Data.SQLite while keeping support for encrypted legacy databases.

We've started with this sample. It all went smooth with .Net 6, but we've encountered absense of System.Runtime.InteropServices.NativeLibrary in .Net Framework (or .Net Standard for that matter). Then we've found SQLitePCLRaw.nativelibrary.dll included in bunch of SQLitePCLRaw packages that was dealing with this issue. So we've reused that library and it did the trick for us.

But now (as of 2.10.0) it looks like you've killed it in favour of including sources of nativelibrary_for_....cs directly into respective platform bundle libs. It kind of make sense, buy I would suggest moving them into SQLitePCLRaw.provider.dynamic_cdecl. Anyway as far as I understand, they are only used in conjunction with it, and if you're under .net framework, there is no way around it at all.

professor-k avatar May 25 '22 14:05 professor-k

I see.

The best workaround I can think of right now is for you to copy the nativelibrary_whatever.cs out of my repo and use it.

ericsink avatar May 25 '22 14:05 ericsink

I think you are correct -- those nativelibrary files should probably go into provider_dynamic, not in the lib packages. As you point out, the public API for provider_dynamic depends on that code. I'm trying to remember if I had a good reason to put them in the lib packages instead, but I can't think of one.

ericsink avatar May 25 '22 14:05 ericsink

Thank you, but workaround is not necessary. I still have v2.0.7 nativelibrary.dll which seems to be still working, and as far as I see there was no real changes to nativelibrary_for_netstandard2.cs in 2.10.0. So I'm fine for now. As for future versions... Well, it would be nice to move from self-made self-host package or ripping files from third party git repository to just official nuget package from official nuget.org.

professor-k avatar May 25 '22 15:05 professor-k