Add support for NugetForUnity plugins

[igor84]

Why would this be useful

Sometimes users would like to be able to add custom functionality to NugetForUnity that is specific to their workflow, or packages they use and they don't see that it would making sense to add it for everyone in NugetForUnity itself.

For example in my company we implemented a "Link source" button next to each package that knows how we keep our projects organized and can automatically find the proper source folder of the given package and replace its folder with a link (windows directory junction) to that folder so that you can edit the source directly from your project.

Or you want to support installing certain packages with native libraries in a some specific way so you can add custom code that will just work with packages you need. We could even provide our own plugin that handles a few most popular nuget packages with native libraries. This could help with issue #419.

How it could be implemented

We would need a separate class library project that would only contain interfaces that we need in order for plugin to communicate with the main NugetForUnity code. That project would need to be built into a dll and installed as a dll with NugetForUnity. It has to be a dll because the plugins need to be dlls so that they can also be loaded from the CLI version.

NugetForUnity could have a setting telling where to look for plugins in the current project. It might even be useful to list and explicitly enable plugins in the preferences window so you can have an option of having plugin code in the project but temporarily deactivating it.

The CLI version would manually load the dlls from that folder and in Unity we would just get a reference to Assembly objects that Unity already loaded and in them we could find a class that has some [NugetPlugin] attribute or implements some INugetPlugin interface for example. It would use some kind of Register calls so that each plugin can register callbacks it is interested in so that it can add additional buttons to DrawPackage method, or handle how are some files extracted or cleaned up in its own way.

We would then just need to define what extension points we want to provide and implement those, plus we should make it so that new extension points can be added in the future without breaking backwards compatibility.

[JoC0de]

I just realized that we need to version the NugetForUnity.PluginAPI separately from the normal NugetForUnity as if we upload the NugetForUnity.PluginAPI as a NuGet package it would contain a version number different than the version number of the NugetForUnity.PluginAPI.dll that we have in the GIT repository / UPM package. So the user will get version conflict warnings. If I have some time I will create a PR. But until this is fixed I wouldn't create a official release.

[igor84]

I'm not sure I understand. Is this related to that option in Unity that should be disabled so it doesn't check versions between DLLs? I think we will have to require this because we can't expect third party plugins to all be updated when we update the Plugin API.

[JoC0de]

Yes one issue is that it would produce the "Unity version check" warning. The other is that we would have a new NuGet package released with each release of NugetForUnity even if we didn't change anything in the PluginAPI. Probably we could just skip versioning of the .dll completely to prevent the warning. Alternatively we can disable the "Assembly Version Validation" setting when we load NugetForUnity.

[JoC0de]

I deployed the PluginAPI to nuget.org https://www.nuget.org/packages/NuGetForUnity.PluginAPI/1.0.0.
Do we need to change some documentation to contain a link to it?

[igor84]

I guess it is only needed in documentation for developing plugin. For using them it should automatically be installed with NugetForUnity and NugetForUnity.CLI.