Gibt es noch das alte simple SQLite?

Moin,
ich habe schon etwas länger keine Datenbanken verwendet. Jetzt brauche ich eine für ein kleines CRUD Projekt. Meine Wahl fiel instinktiv auf SQLite. Leider finde ich die Version nicht mehr, die ich gewohnt war.
Was ich meine, sieht man hier auf der Microsoft-Seite:
https://learn.microsoft.com/de-de/dotnet/standard/data/sqlite/?tabs=netcore-cli

Als ich das letzte Mal SQLite benutzt habe, hatte ich einen "normalen" SQL-String, den ich mit C#-Variablen dynamisch füllte. In der Microsoft Version muss man jetzt Commands kreiren, sie mit API spezifischen Variablen füllen, diese "Parameter" dann noch spezifizieren und anschießend das ganze ausführen. Viel zu umständlich für das, was ich vorhabe.
Wenn ich das richtig verstanden habe, basiert das auf ADO.net.

In VS Code wird im Nuget Package Manager als erstes Ergebnis SQLite 3.12.3 angezeigt. Aber diese Version kommt ohne Referenzen. Die Version System.Data.SQLite hingegen ist wie die Microsoft.Data.SQLite aufgebaut, also auch nicht das, was ich suche.

Gibt es das "normale" SQLite noch, ohne ADO.net?

Mir ist ein Rätsel, wovon Du sprichst.
Das einzig offizielle, aktuell unterstützte und supportete Paket ist Microsoft.Data.Sqlite
System.Data.SQLite ist das alte Paket,

Und wenn ich mich richtig erinnere, gab es niemals ein offizielles Paket (von Microsoft oder vom Sqlite Team) ohne ADO.NET.
Kannst natürlich die nativen Libs nehmen (das ist das Paket Sqlite, deswegen hats keine Dependencies) und die ganzen Wrapper selbst schreiben.

Als ich das letzte Mal SQLite benutzt habe, hatte ich einen "normalen" SQL-String, den ich mit C#-Variablen dynamisch füllte.

Der einzig korrekte, sichere Weg für das Füllen eines SQL Strings sind Parameter. Schon immer gewesen, nicht nur in .NET.
[Artikelserie] SQL: Parameter von Befehlen
Auch das war bei SQL bzw. Datenbanken nie anders.

Klingt fast nach einem Micro OR Mapper ala Dapper.
Weil mit reinen SQLite hast du schon immer mit Connection und Command Objekten in C# gearbeitet.
Dies bildet den Kern der Kommunikation zwischen deiner Software und den Datenbanken wie SQLite.

Du kannst aber gerne mal Beispiele und Informationen zu der "alten" Version liefern.

T-Virs

Ok, das hat mich jetzt sehr überrascht. Aber nach einem Blick, tief in meine Projektkiste, habe ich die Lösung des Rätsels gefunden. Erstmal: ja, ihr habt Recht, SQLite war auch schon früher mit ADO.net, und auch von der Code-Struktur her gleich.
Ich habe mir irgendwann einen kleinen Wrapper geschrieben, benutzte dann SQLite immer auf diese Weise und habe irgendwann vergessen, daß es ein Wrapper war. Jetzt, nach längerer Zeit, suchte ich nach meinen Geistern, die ich für SQLite hielt. 🙂

Im Bestfall kannst du ja z.B. mit Entity Framework Core 6+ arbeiten.
Damit brauchst du dann kein SQL mehr sondern arbeitest über Code mit reinen Klassen.
Dürfte noch besser sein als mit ADO .NET alles selbst bauen zu müssen, darum kümmert sich dann Entity Framework unter der Haube.

T-Virus

@Abt @T-Virus
Ja es gibt eine weitere, viel einfacher zu benutzende Variante von SQLite und die hat nichts mit ADO.NET zu tun.
https://www.nuget.org/packages/sqlite-net-pcl/
Ist dadurch aber wirklich nur für "Kleinigkeiten" zu gebrauchen, wobei sie auch unter Android und IOS funktioniert

Wenn ich da so über die Beispiele scrolle - wo ist der Vorteil gegenüber dem Entity Framework?

Es kann bei weitem nicht was EF kann, aber es ist kleiner und durch direkte ( PInvoke ) Einbindung schneller.
Auch ist es gerade durch etwas wie Connection.CreateTable<T>() sehr einfach das DB Schema zu pflegen.

Ich benutze es für viele kleine Tools, aber ich weiß was ich tue ( meistens 😉

Sieht aber auch nicht danach aus, dass das Projekt noch großartig aktiv ist.
Letzte Änderung war vor 13 Monaten und es gibt fast 500 offene Issues sowie 47 Pull Requests, wo von einige sogar bis 2018 zurück reichen.
Dabei geht es auch um den Einbau einer Fluent API, was dann auch stark in Richtung EF Core geht.
Dann kann man sich aber die Frage stellen, warum man nicht gleich zu EF Core wechselt.

Die Performance von EF Core war eigentlich bei meinen Tests seit .NET Core 2.x selten ein Problem.
Eher die Clientseitigen Filterungen/Sortierungen etc. die aber weitestgehend auf Serverseite verlagert wurden.

T-Virus

Gibt schon noch Gründe gegen EF Core... so ist es ja nicht.
Das Marketing ist hier auch riesig, was die Einfachheit betrifft - aber die Realität zeigt so oft, dass das halt nicht so funktioniert.
Spätestens wenn man mehr machen will als ein Tool.

Ja es gibt eine weitere, viel einfacher zu benutzende Variante von SQLite und die hat nichts mit ADO.NET zu tun.

Daran erinner ich mich auch noch vage; habs sogar vor Jahren mal aktiv genutzt und ich habs auch in den NuGet Treffern gesehen. Deswegen hab ich auch bewusst geschrieben

Das einzig offizielle, aktuell unterstützte und supportete Paket

Wenn ich da so über die Beispiele scrolle - wo ist der Vorteil gegenüber dem Entity Framework?

Es wird immer die Einfachheit und die "rohe Performance" beworben. Aber das hast mit EFCore auch, kein Grund also mehr.
Den bemängelten "unnötigen Overhead" stammt noch aus EF4 Zeiten.

Im Endeffekt sind es nun noch die Gewohnheitstiere und die Anti-EF Fraktion (zu der ich zu EF-Zeiten auch mal gehört hatte).

@T-Virus
SQLite-net ist ja nur die Schnittstelle zu SQLite selber und 90% der Issues sind eher dem Unverständnis geschuldet wofür das mal gedacht war.
SQLite-Net ist nicht als Ersatz für Enterprise ready Libs wie EF/Linq2DB/NHibernate gedacht, sondern für "Kleinigkeiten".
Sieht man schon am Fehlen von Child support etc.

Und es benutzt https://github.com/ericsink/SQLitePCL.raw unter der Haube, und das wird schon noch anständig gepflegt.

@Abt:
Es gibt so viele Menschen da draussen die immer noch bei .NET FW bleiben wollen/müssen und da nutzt mir EF-Core nicht so sonderlich.

Aber mein Einwand war nicht, das man es unbedingt benutzen sollte, sondern eine Antwort auf die Frage ob es auch was anderes gibt als die ADO.NET basierte Version.

Und noch einmal, hier geht es nicht um Client/Server.