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!