Tentative direction for System.Data.SQLite 2.x

(1) By Eric Sink (ericsink) on 2025-07-01 16:57:07 [link] [source]

I am working on a new and more modern version of System.Data.SQLite.  Because I intend to remove support for a bunch of older things, the version number would change from 1.x to 2.x.  For now, everything here should be considered tentative, and feedback is welcome.

(1) Remove: Windows CE, compact, etc

(2) Remove: Visual Studio integration, aka Design-Time components, etc

(3) Change: Minimum version of .NET Framework:  netstandard 2.0 and .NET 4.7.2

    (3a) Undecided: System.Data.SQLite.Linq.  This code targets pre-netstandard20

(4) Keep: Entity Framework 6 and netstandard 2.1

(5) Add: Cross-platform support for .NET 8+

    (5a) Linux, macos

    (5b) Maybe: iOS, Android

    (5c) Move the help system away from CHM

    (5d) Hopefully: Adapt the test suite to be less Windows-specific

    (5e) Undecided: Mono support

    (5f) Hopefully: Support for Entity Framework core

(6) Remove: SQLite.Interop.dll

    SQLite.Interop.dll is a shim between the managed code and SQLite itelf.
    On Windows, this is implemented in C++/CLI.

    The System.Data.SQLite code also supports more direct P/Invoke of SQLite
    without the shim. This approach has become the prevalent way of doing native code 
    interop with .NET.

(7) Change: Separate build systems for managed and native code

    (7a) Use SDK-style projects for building the managed parts

    (7b) Deal with compilation of the regular SQLite library separately

(8) Remove: Installers

(9) Keep: nuget packages

(2) By anonymous on 2025-07-02 16:52:39 in reply to 1 [link] [source]

None of this sounds like it would be a problem for me, and these changes sound like they would make System.Data.SQLite a bit easier to both maintain and use. As I previously mentioned, moving away from CHM would be a positive at least for me. I don't find design-time support very useful, as my projects work with dynamic schemas that can't be fixed at build time.

I use the Session extension via System.Data.SQLite (this is one of my main reasons not to use Microsoft.Data.SQLite), so I would be concerned if that support were being dropped, but it doesn't sound like that's being considered.

I might need to tweak my build process somewhat if SQLite.Interop.dll were dropped as I currently load System.Data.SQLite.dll dynamically without a .deps.json file, but I believe it wouldn't be very difficult as long as System.Data.SQLite were still able to load a SQLite library relative to itself.

If the version number is changing to 2.x, it might be a good opportunity to start making better use of the minor version number going forwards, improving from the pattern of every release being 1.0.x.

(3) By anonymous on 2025-07-08 13:34:53 in reply to 2 [source]

SQLitePCLRaw was mentioned a couple times on the other thread, but I don't think that it necessarily makes sense to use a specific low-level SQLite binding unless that would actually be beneficial either for development or to users of System.Data.SQLite.

Ultimately what matters from my perspective as an application developer is not the specific implementation of the raw SQLite binding but how easy it is to provide System.Data.SQLite with a native SQLite. If SQLitePCLRaw would make that easier, great, but a direct P/Invoke-based approach that can use an ordinary libsqlite.so or sqlite.dll sounds like it would be easy to use.

(4) By Eric Sink (ericsink) on 2025-07-08 15:08:22 in reply to 3 [link] [source]

To be clear, if I were to make a version of System.Data.SQLite which used SQLitePCLRaw (which still isn't all that likely), it would be an experiment, and at most it would end up as simply an optional configuration, not a required dependency.