.NET install support

[aaronpowell]

I want to use this with the .NET Sqlite library but there's no .NET/NuGet package that it's provided via which causes a bit of a workaround to use (manually copying the file).

NuGet packages support multiple architectures so it should be possible to bundle and ship a package.

Here's mod_spatialite as an example.

[asg017]

I'm down to add a nuget package for sqlite-vec! Thanks for sharing the mod_spatialite sample, that helps a lot

Do you mind sharing what your current code looks like? I've never tried .NET before and wanna make sure my mental model is right

[aaronpowell]

To use it in .NET you would do:

var connection = new SqliteConection(<connection string here>);
connection.LoadExtension("vec0");
// open and use

I'm still doing some experimentation, but from the looks of it, you just need to provide the path (absolute or relative) to where the extension is on disk. If you just do vec0 it'll look in the same folder that the DB is (that's what I've tested in my hacking), and I'm experimenting how to load it from a different location.

Once I have a better idea, I'm happy to submit a PR

[aaronpowell]

Came across a sample - https://github.com/dotnet/docs/blob/main/samples/snippets/standard/data/sqlite/ExtensionsSample/Program.cs

It does require a bit of additional work, but that's at the consumer end, so something that wouldn't be shipped by this package

[asg017]

Sweet, thanks for sharing! Another sample from the spatialite project: https://github.com/bricelam/mod_spatialite-NuGet/blob/master/test/Spatialite.Tests/Program.cs

Hoping we can avoid the EnsureLoadable() stuff for sqlite-vec, hoping to have an API like:

var connection = new SqliteConnection('...');
SqliteVec.load(connection);

That matches the Python/Ruby/JavaScript APIs we have. That way we can resolve to the correct vec0.dylib/vec0.so/vec0.dll at runtime instead of manually editing the path

For generating the nuget package, ideally I'd like to package it with the sqlite-dist project that I use for building all the distritbution packages for SQLite extensions. That contains the code that manually creates the NPM/pip/gem packages from scratch, so would love to add a nuget option there.

(but dont worry about that, I can add that code, it's confusing code in Rust)

[aaronpowell]

I'd actually recommend to not include the loader logic, just the extension binaries, so then it becomes the responsibility of the consumer to load using whatever logic is going to make the most sense.

For example, I want to use it in conjunction with the change I'm working on here: CommunityToolkit/Aspire#428

For this to work, I'd have code like this in the app host (defining the infra):

var vectors = builder.AddSqlite("vectors").WithExtension("vec0");

builder.AddProject<Api>("api").WithReference(vectors);

Then in the client (the API project) I would write:

builder.AddSqlite("vectors");

And the Aspire integration takes care of loading the vec0 extension. It also means I could have multiple extensions defined and the client that receives the info on how to connect to the SQLite db can load them all based off expected logic.

[krwq]

Hey @asg017 I've added you as a collaborator to my repo https://github.com/krwq/SqliteVec/invitations where there is an example code how to create such nuget package from binaries in this repository but I think this repo is better place for this nuget package as you could automatically provide updates.

This is currently using powershell and .NET 8 to build the package. Please let me know if you have any questions. I can also help adding it here but I'm not super familiar with the code here.

[krwq]

Note that the package produced by @aaronpowell's PR needs efcore fix in order to work with dotnet run correctly: dotnet/efcore#35617 - it's already merged and backported to 9.0 and 8.0 branches of efcore repo.

In simple words, whenever the new version of https://www.nuget.org/packages/Microsoft.Data.Sqlite.Core shows up it should contain the necessary fix. Without this change it's necessary to pass in runtime identifier when running dotnet, i.e. -r win-x64 or otherwise native asset will not get detected correctly.

[roji]

Still commenting to not forget .NET Framework when doing these bindings, which may require some additional things in the nuget package etc.