Make it possible for managed plugins/addons to specify external dependencies

[mlavik1]

TLDL: It would be nice if C# addons and editor plugins could specify external dependencies, and the editor auto-resolves these during plugin import. Two suggestion: The plugin lists required NuGet packages (per platform!), or a path to a .csproj to be auto-included when installing the plugin.

When making C# plugins, I haven't been able to find a "good" way to deal with external dependencies (to managed and/or native libraries). Referencing these in your own game project would simply be a matter of fiddling with the .csproj a bit, maybe adding some <Reference Include=SomeLibrary> for referencing .dll/.so files, or <PackageReference ..> for NuGet packages.

However, the big challenge is finding a simple way for people to add your plugin to their own game projects. I've seen some plugins that create a demo project in the parent directory of the "addons" folder, where they reference the libraries in the .csproj file, and then they simply tell the users to manually copy over the relevant lines from the cs project file. Others use NuGet, and then tell their users which NuGet packages they need to use their library.
A third option, that I havent' seen many do, would be to create a .csproj for your plugin where you reference all required libraries, and then the users to simply include that. That's maybe even simpler?
I've also seen people copying whole C# libraries into a subfolder, to make sure users can use their plugin without having to fiddle with any .csproj files..

Either way, there doesn't appear to currently be any ways of creating C# plugins with external references that just work out of the box when imported into Godot. This would be really nice to have though!

I have two suggestions:

1. The ability to list (in some file?) all required NuGet packages. Note: You may need different NuGet packages for different platforms (if they include native libraries).
2. Make Godot Editor auto-detect if there is a .csproj file inside of addons/AddonName, and if so: Automatically add it to the project file when installing the addon. Alternatively, this could be optional.

(please let me know if there are any solutions to these problem - but I'm pretty sure it's not, after spending lots of time fiddling, asking on the forums and in the Chickensoft Discord - sorry if I'm wrong though!)

[donovani]

I'd really like this as well. An addon's dependencies are an implementation detail and should not be a concern for the end user. This is true for pretty much all package managers. Expecting the end user to know all of a project's dependencies feels very backwards.

I think there's probably room for discussion on how this can be handled though. The core of the problem is that C# plugins currently don't have any way to "include" the dependencies along with it. Any solution to this limitation is acceptable to me, though I'd prefer it be as painless as possible to the end user. Some ideas that come to mind:

• Godot could support a separate package.config file* in the addon directory
• Creating a system to "export" C# addons with the dependency files included

* = An addon repo generally has a .csproj file in the root directory, so I feel like having another .csproj in the addon folder might be an odd choice. Hence the suggestion for a packages.config - which should still be supported by the .NET SDK.

[willnationsdev]

I feel like the crux of the issue here goes beyond merely C#. Effectively, we're looking for the editor to scan addon directories, detect the presence of a specific scripting language's files, and then have that trigger a follow-up operation that 1) seeks out some sort of dependency configuration file affiliated with the addon, and 2) triggers a process that initiates the process of importing & loading necessary dependencies for that language.

For example, you could have a ScriptLanguageDependencyLoader class (exposed to scripting) that could handle these tasks. The engine could provide an "official" one for C# & .csproj or packages.config files to be discovered and then trigger a nuget restore command (or similar). Then, if people want to create alternative solutions for a particular scenario or to support a different language, the engine will have given them the tools necessary to resolve it themselves however they wish.

cc @donovani