Up-to-date version?

[Blubberblub]

Did you try this out with newer versions of the Kuzu lib files? The ones in the repository are a little older and i got syntax errors from swig when trying the process on newer lib files. Also i seem to miss libkuzu.lib in the newer precompiled Kuzu lib files. Where is this from?

[FactEngineCommunity]

I tend to respond better to questions with a salutation, like "Hi there", Blubberblub, but I'll help you out as best I can.

1. Do you want to contribute to this project? I've spend USD $600 on this out of my own pocket. If you want to chip in, that will be welcome;
2. Can I ask? Did you actually need to make new DLLs? I mean, did you try the existing DLLs against Kuzu? They are in: KuzuDB-DotNetInterface/KuzuDB-net/KuzuDB-Net/bin/Debug/
3. libkuzu.lib is in KuzuDB-DotNetInterface/KuzuFiles, but do you mean "Where are is the latest version of libkuzu.lib?". Try the Kuzu website/team. After you've got your code working...why not collaborate on this project and push your new working code for a newer Kuzu here? Sound good?
4. "this" from? I don't understand the question. If you mean libkuzu.lib, try the Kuzu website.

Thanks Blubberblub. When you get your code working, please get in touch, I'll add you as a collaborator and you can push the code to this repository so everyone can enjoy.
Victor
FactEngine

[Blubberblub]

@FactEngineCommunity Hey Victor,
thanks for the reply. My question wasn't meant as a "can you please do this?" but more to ask if someone already tried it. I just started to dig into everything that is in the repo here and my first thought was to try it out with the most recent libs from the Kuzu website. This is when i was running into syntax problems with swig, since the header file changed quite a lot compared to the version in the repo here.
Regarding your 2. point: I will try out the ones in the repo for now and see if i hit limitations.
Regarding your 3. point: In the newer C/C++ libs from the Kuzu website there is no libkuzu.lib file, so i was interested in the origin of the file. Finally if i manage to find a solution i will get in touch.

[FactEngineCommunity]

Hi Blubberblub, I wonder if you/we can't just use the (new) DLLs in the C/C++ download from the Kuzu website. Might work just fine with .Net. They might be from here though, I don't know.
Sure thing, let me know how it goes. Kind regards, Victor

[FactEngineCommunity]

Hi Blubberblub, I've updated the ReadMe.MD with the files needed for a .Net app:

Imports kuzunet

Put the following files in your .exe directory:
kuzu_shared.dll
KuzuDB.dll
kuzunet.dll
libkuzu.lib

.Net needs Kuzu, so if you have any insights for how to improve doco on this repository, please let me know.
Kind regards, Victor

[anthonyh-paralog]

Hello,

I was able to resolve the swig error by adding the following to the top of the swig input file:

#define KUZU_EXPORTS
#define _WIN32

[FactEngineCommunity]

Hi @anthonyh-paralog, mind sharing which of the to .i files you put it in, and where? Code snippet would be good. Got a feeling Kuzu is going to be around for a while, so the cleaner this repo the better. I'll keep it alive.

E.g. Did you put it in kuzi.i under the #include

%module kuzunet
%{
/* Put header files here or function declarations like below */
#include "kuzu.h"
%}

[anthonyh-paralog]

I ended up forking and making a new sub-project (KuzuDB.NET) aimed at collapsing down the swig/cmake interaction to build steps. My thinking was that, it would be nice to be able to reference KuzuDB Net as a nuget package... Did not quite make that happen 😅 (possibly need to use github actions to provide the swig/cmake tooling for producing a package)

You can find everything here:
https://github.com/anthonyh-paralog/KuzuDB-DotNetInterface/tree/main/KuzuDB-net/KuzuDB.NET

I had to somewhat fuse things together since there appeared to be 2 different methods weaved together

Note: KuzuDB.NET assumes that a recent-ish version of cmake is installed and available on the PATH (i have 3.28)

[anthonyh-paralog]

@FactEngineCommunity sorry, to answer your question more directly, here's the kuzu.i file:
https://github.com/anthonyh-paralog/KuzuDB-DotNetInterface/blob/main/KuzuDB-net/KuzuDB.NET/kuzu.i

[Blubberblub]

@FactEngineCommunity @anthonyh-paralog Thanks for your explanation and the solve for the SWIG issues. I forked this project and changed a few things:

1. I put all the generated files as well as the Kuzu lib files in gitignore, since they depend on the version of Kuzu you want to use. I don't thinks the generated wrapper files, etc. should be in the repo, but should be generated by the user depending on the Kuzu version he/she wants to use.
2. I moved all the readme from the single steps to the main readme to make transparent what steps one has to take to make this work
3. I added some remarks on the dependencies used to make this work as a reference for recreating this. The many different parts involved make it likely something is going to fail when building with different versions of the components involved.
4. Tested it with the most recent Kuzu version.

The fork can be found here:
https://github.com/Blubberblub/KuzuDB-DotNetInterface

This is just a small attempt to make this a little bit easier to recreate. Some things i think should be added:

• Better information on the single parts and their outcomes from someone who understands the process better
• A basic example project or description that shows how the libs can be used without linking to the KuzuDB-Net project in a C# project

Also I'm not experienced with contributing to github projects so someone would have to tell me how make this a contribution to the main repo.

[FactEngineCommunity]

Hi BlubberBlub
Thank you. Here's my thoughts/suggestions:

1. I've added you as a collaborator to this repository. I believe you just have to accept the invite;
2. You can move your code/suggestions to this repo locally on your machine and do a push/commit back to this repo;
3. Can I ask a favour...can you please leave the Bin\Debug or at least move the generated .DLLs to the Test application, and recommit that (the test application)...so that people can just come here and get the .DLLs they need;
4. Per 3 (above)...many people may not have the time and/or experience to generate their own DLLs using SWIG/C++ etc.
   If that's the case...let's be helpful and just say "In a hurry? Here's the latest generated DLLs".

Reason being, against each file is a date, so people will know how old the DLLs are, and you've kindly put the version of Kuzu that we/you generated the DLLS against in the main ReadMe. So someone may say, "That'll do...just give me the DLLs" etc.

Many thanks again. Much appreciated. I agree...more notes need to be added to explain how to generate the DLLs etc and using SWIG/C++/C to get what we want, but more people will jump on board and help out.
Kind regards,
Victor

[Blubberblub]

@FactEngineCommunity Hey Victor, i will add the changes to the repo next week. For the generated DLLs maybe we could add them as releases with versioning to the repo and add a section to the readme explaining where to find them and how to use them? Then people can download them directly without generating anything. For the generated wrapper files we probably could leave them in the code and use versioning tags equivalent to the Kuzu version they apply to? I don't now how this could be best handled with the examples though.

[anthonyh-paralog]

Just wanted to add; it would likely be a good thing to have the repo publishing nuget packages so users can discover+import what they need without having to dig to deep into the details here. There's a lot of down stream things that depend on graph databases (kuzu, neo4j, etc..)

[FactEngineCommunity]

Hi all, I haven't made a NuGet package before. I'll have a look into it. If you've got experience please feel free to put one here.

• Versioning: Yes, I think how you have done, mentioning the version made against
• Wrapper Code/Versioning - Sounds good. Whatever is simpler for users.

[anthonyh-paralog]

Here's another project that might be worth studying:
https://github.com/jeikabu/nng.NETCore/tree/master

primarily for the whole build, packaging and publishing bit (github workflows)

thank you for this project, i'll be spending a lot more time with it next week.