Ask questionsConsider bringing back dllimport
During the development of SQLitePCLRaw 2.0, my hope was to get rid of most of the provider implementations and use the "dynamic" provider in all cases.
The basic idea of the dynamic provider is this: Instead of using DllImport attributes, dynamically load the shared library and look up all the names needed.
This was intended to solve two problems.
(1) DllImport requires the name of the shared library to be hard-coded at build time, so the provider has to be recompiled for every name we need. Using a custom SQLite build with the name provided by the app is impossible.
(2) DllImport doesn't allow control over where the shared library is to be found. The hope is that by having finer control over this, we could gain the ability to deal with the nearly constant stream of people having trouble with "e_sqlite3 not found" errors.
Overall, this didn't work out well. I keep encountering cases where it is necessary to just use DllImport anyway. In the end, the dynamic provider probably increased the number of builds instead of its goal of decreasing that number.
And we seem to have just as many people struggling with inability to locate the shared library. Maybe more.
The dynamic provider is implemented using
System.Runtime.InteropServices.NativeLibrary. But that API was new in .NET Core 3, so I implemented a subset of it for use on .NET Framework. But there have been problems wherein my implementation doesn't behave the same way. See #389 for example.
Note also that
System.Runtime.InteropServices.NativeLibrary includes an API to configure the way DllImport lookups are resolved. I'm not currently using this, but it would present another alternative for the problems above, staying with DllImport plus a configured resolver instead of using
It is not clear that the dynamic provider has added anything except complexity.
Answer questions ericsink
Note to self:
The previous comment from @jeromelaban appears to contradict the following sentence I wrote a bit further up:
FWIW, the dynamic provider is used on .NET Core, and it doesn't seem to be causing any trouble there (that I can remember). There is probably little reason to change this case to use dllimport.