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)

> The bindings are an interface to a C library that should be shipped with the device.

There is nothing stopping you from statically linking it with the rest of your code.

How exactly would you link a C library to a .NET application?

Apart from compiling it using something like ilcc, that is.

.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.

It's not entirely cross-platform, but it is possible. Example: https://developers.redhat.com/blog/2016/09/14/pinvoke-in-net...

More details in the .NET Standard: https://docs.microsoft.com/en-us/dotnet/standard/native-inte...

[1] One interesting reference site: https://www.pinvoke.net/

That isn’t that simple. https://www.sqlite.org/download.html has separate libraries for 32-bit and 64-bit windows, and you have to write code to figure out what DLL to load (see http://system.data.sqlite.org/index.html/doc/trunk/www/faq.w...)

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.

That's an interesting technique, and would certainly work.

You could probably even make it cross-platform that way.

Maybe you could help me understand why static linking is a requisite of FFI?

Oh, d--n it, misread. Never mind.

No problem; it happens!

The value of SQLite lies in its implementation, and a native implementation would be immensely costly.