[System.Data.SQLite] Using sqlite3.dll instead of Interop.dll - what's the trade-off?
(Sorry if this becomes a double post - I first tried posting from Nabble)
I've compiled System.Data.SQLite.dll with the
"/property:UseSqliteStandard=true" option, so that it will load
sqlite3.dll (or it's Linux equivalent) instead of SQLite.Interop.dll.
The advantage of this is that you can run the exact same code on Windows
and Mono+Linux without resorting to using the rarely updated
Mono.Data.SQLite package (about 1.5 years old right now, and with
unfixed bugs critical to my application).
My question is: what are the trade-offs of not using SQLite.Interop.dll?
Re: [System.Data.SQLite] Using sqlite3.dll instead of Interop.dll - what's the trade-off?
John Reynolds wrote:
> My question is: what are the trade-offs of not using
There are various compile-options and extensions baked into the
"SQLite.Interop.dll" that are not enabled and/or included by
default with "sqlite3.dll".
One that is somewhat important, is the "vtshim" extension. It
is required if you want to implement a virtual table in managed
code. It's also fairly tightly integrated into the resulting
"SQLite.Interop.dll", by necessity.
It is possible to compile the "SQLite.Interop.dll" for Linux,
Mac OS X, and probably other POSIX compliant systems, using
the following build script: