search

ericsink / SQLitePCL.raw

A Portable Class Library (PCL) for low-level (raw) access to SQLite
Apache License 2.0
512 stars 106 forks source link

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

Open professor-k opened 2 years ago

professor-k commented 2 years ago

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.

ericsink commented 2 years ago

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 commented 2 years ago

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.

professor-k commented 2 years ago

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.