How to reference a library ( managed DLL) in a C# addon

Question

I have an addon that needs to use a library (managed DLL). Currently I do this by adding a reference to it in the .csproj of the project using the addon, like this:

<ItemGroup Condition="Exists('lib\MyLibrary.dll')">
    <Reference Include="MyLibrary">
      <HintPath>lib\MyLibrary.dll</HintPath>
    </Reference>
</ItemGroup>

However, this is quite inconvenient, since anyone using my plugin will have to copy-paste that into their own .csproj manually. And it gets worse when dealing with managed libraries that depend on native libraries, since I'll need to add platform dependent condition-checks => more to copy!

Is there way to add this dependency to the addon directly, so that users can just add my addon to their project without having to do any extra work? Can addons somehow define their own .csproj files? (ideally without users having to manually include my .csproj from theirs)

Thanks!

Persephone

Answer 1

You could have a submodule (assuming git) that someone else could include in their project. However, why not just publish a package, e.g. to nuget? That pretty much covers everything you mentioned and allows a user of your library to control dependencies, restore via package management, etc.

Dragone

Answer 2

Thanks for the reply! Publishing to nuget is a great idea! However, maybe I wasn't clear enough in my question: My problem is less about how to get the DLLs but more about how to reference them in a way that doesn't add extra work for users of my addon .

For an addon that doesn't have any dependencies, users can simply add it to their "addon" folder, build and then enable the addon. For plugins that have dependencies I'm not sure what's the best way to add those dependencies. I see two possibilities:

• Tell users what they need to add to their .csproj for my addon to work ("<PackageReference>" for NuGet, etc.)
• Make a .csproj for my addon, and tell users to include that in their .csproj

Either way, the users will need to modify their .csproj to use my addon, though the second option seems simpler. I'm still new to Godot, so I'm not sure if it's common practice though. And are there any other alternatives that I'm not aware of? If not, I'll probably go with that 🙂

Persephone

Answer 3

No, that’s not right - if I give you a library or addon that has its own dependencies, it has no affect on your code; it’s self contained, you don’t need to reference anything about the dependencies.

If you’re shipping as source then perhaps, although I’d expect a good library would pull its own dependencies and the build system to take care of that. Yes, the dependencies are present and used by your code so godot can run the addon, but user code won’t care unless you’re leaking implementation.

For example, if I use Newtonsoft.Json in my project and ship it as an addon, the user doesn’t need to know or do anything as my project handles that for the user code. I likewise for native code.

Dragone

Answer 4

I’d expect a good library would pull its own dependencies and the build system to take care of that

That's exactly the problem I'm trying to solve 😅

So regarding your example:. How would you reference Newtonsoft.json in your addon? Do you create a .csproj for your addon (stored under "addons/youraddon/youraddon.csproj") and reference it there? (with "<PackageReference Include="Newtonsoft.Json">").

And that works fine without users having to include your addon's .csproj from theirs? Because when I tried that (without NuGet though) the result seemed to be that the addon's .csproj was ignored, and when building a project using the addon in Godot, addon's code was built as part of the outer project directly - resulting in build errors, unless I reference the library in the outer project's .csproj.

Oh, and just to be clear: I'm talking about developing Godot addons/plugins - not C# libraries, as described here: https://docs.godotengine.org/en/stable/tutorials/plugins/editor/making_plugins.html

Persephone

Answer 5

Right, an editor plug-in is different from an add-on. A plug-in lives in your game project.

The documentation shows how to work with nuget in godot here: https://docs.godotengine.org/en/stable/tutorials/scripting/c_sharp/c_sharp_basics.html#using-nuget-packages-in-godot. If you're using a sensible IDE, just add it as a package reference rather than hack project files, or use the command line. Note that packages are automatically downloaded.

Your inspector plug-in could form a template to use with all your projects, albeit it likely linked to something specific to your game. If you're shipping a template for someone else, the solution and project will already be created as part of the template, packages downloaded automatically. It makes sense that if you put it in a different project, godot doesn't know anything about it until added to the godot solution (e.g. when creating a project).

If you were to build an add-on instead, it's self-contained and targets the engine - no further tweaks required in the game project.

Dragone

Answer 6

Ok, maybe I'm confusing the terminology. What the Godot reference refers to as "editor plugins" are plugins that live in the "addons" folder - so I assumed these two terms were used interchangeably. By add-on, do you basically mean pure C# code (og Godot scripts) that can simply be copied into a project?

But yes, what I'm working on is an editor plugin. And it's not for a game, but for other users to use (my original Unity plugin was used by researchers, students, startups, etc.), so it's not an "internal" thing. That's why I wanted to make it simple for people to add it in their own existing projects. But I think I'll go for your original suggestion, and make a NuGet package for the external library - then all our users need to do is to add that package to their own project. It should be simple enough 🙂
Thanks a lot for your help btw!

Persephone