A C# native port[0] of Sqlite was attempted in 2009 and eventually abandoned in 2012. It was a lot of work and the developer didn't get 100% of the verification tests to pass.
To be fair to the programmer, he said the C-to-C# translation was mostly a self-learning exercise rather than a serious attempt at creating a production-quality library.
I think the obvious answer is that there's no market demand for a C# native version of SQLite. People just use the C# ADO.NET wrapper that calls the "unsafe" C compiled DLL[1]. Using that method, it's easier to stay up-to-date with the canonical C source code that has the latest bug fixes and new features. If you look at high frequency of updates in the release history[2], you can see that constantly porting the new C code to C# to maintain feature parity would be a tremendous amount of work.
Also, if you create a C to C# port, it means using the C Language style API such as "sqlite3_open()" instead of the more natural C# paradigm of ADO.NET "new SQLiteConnection(@"Data Source=x")". Somebody would than have to write another ADO.NET wrapper to specifically interface with the C# port of SQLite.
> Also, if you create a C to C# port, it means using the C Language style API
Is this really necessary? Is it impossible to just write a .Net-native library with whatever an API that would just open an SQLite file and run SQL queries against it? As for me that's all I ever needed of it.
>Is it impossible to just write a .Net-native library with whatever an API
It's not impossible but the issue is whether it's worth the amount of effort involved. So yes, you can theoretically write the C# code in any way that makes a convenient API for the C# coder.
But when attempting real-world implementations, there are varying degrees of difficulty/maintainability of porting the C code to C#. You want to balance the tradeoffs of minimizing the C# programming code effort and maximizing the leverage of the original C source code. The effort continuum would look something like this:
- easy: unsafe C DLL with C# ADO.NET wrapper (the 'C' source code is mostly unchanged and is leveraged for highest reuse; this is what we have today)
- harder: straight C-to-C# port with extra C# code to provide an ADO.NET wrapper (an automated tool can attempt to transpile most of the C into C# which is followed up by a human programmer to manually fix/code the parts the transpiler couldn't; this effort was attempted in 2009 and the incomplete project was eventually abandoned)
- hardest: C-to-C# total rewrite where the programmer built in an ADO.NET api (or whatever API the C# programmer wants to expose). In this way the original SQLite C source is more of a "specification" rather than an input file to a transpiler.
The "harder" effort which wasn't even 100% complete was abandoned. It means the "hardest" implementation, while technically not impossible, is even more unrealistic for anyone to code and maintain. That last method of C# rewrite has immense costs and would fall further and further behind the original C source code in feature parity and bug fixes.
To answer your question on why there are no alternative implementations: it's because it's a lot of programming work that nobody wants to do.
To be fair to the programmer, he said the C-to-C# translation was mostly a self-learning exercise rather than a serious attempt at creating a production-quality library.
I think the obvious answer is that there's no market demand for a C# native version of SQLite. People just use the C# ADO.NET wrapper that calls the "unsafe" C compiled DLL[1]. Using that method, it's easier to stay up-to-date with the canonical C source code that has the latest bug fixes and new features. If you look at high frequency of updates in the release history[2], you can see that constantly porting the new C code to C# to maintain feature parity would be a tremendous amount of work.
Also, if you create a C to C# port, it means using the C Language style API such as "sqlite3_open()" instead of the more natural C# paradigm of ADO.NET "new SQLiteConnection(@"Data Source=x")". Somebody would than have to write another ADO.NET wrapper to specifically interface with the C# port of SQLite.
[0] https://code.google.com/archive/p/csharp-sqlite/
[1] https://system.data.sqlite.org/index.html/doc/trunk/www/down...
[2] https://www.sqlite.org/changes.html