I think the parent means native implementations so that these bindings are not necessary. The bindings are an interface to a C library that should be shipped with the device. I can see how that can be problematic if you're targeting OS X, Windows, and Unix systems
The OP is saying problems exist before even deployment concerns:
> even if it actually starts working nobody really knows how to deploy such an app on another computer (especially if it runs a different kind of OS) correctly.
emphasis mine.
(and portability could obviously be solved the same way it was in Python: ship sqlite as part of the core system)
.NET has always had a foreign function interface (FFI) system called P/Invoke [1] or Platform Invoke. You build a DLL and ask the .NET runtime through metadata to load that DLL for you and call the functions you need.
Nowadays, you mostly can ignore x86, but I guess you still hit similar problems if you want your code to run on Windows for ARM, .NET core on Linux, etc.
I'm aware of P/Invoke. I'm pretty sure that's how the ADO.NET wrapper to SQLite works. GP was referring to statically linking a native binary to a .NET application, and as far as I know, there's no way to do that.
I was curious. One approach is apparently to include it as a binary resource, extract it to temporary space at runtime, then P/Invoke: https://stackoverflow.com/a/768429
That seems a bit much to simulate static linking, but doesn't sound like it would be too noticeable to users.
