C# plugin install process

Somehow I seem to have broken my plugin when updating from R6 to R7. So I want to use it as an opportunity to clean things up a bit. My problem it as follows:

  1. clean r7 install
  2. install plugin, works fine
  3. close rhino, reopen, run plugin, doesn’t run
  4. try to reinstall plugin, “unable to load, plugin ID in use”

Understanding exactly how this works has been on my list for years…I originally started from the example provided by Dale, but suddenly I can’t get it to work.

First question, what are the minimum classes that I need to declare a GUID attribute on. So far I know:

  1. Any WPF panel hosts need Guid Attributes
    The assembly manifest? It implies this will be the Guid of the “plugin”
  2. [assembly: Guid(“xxxx…”)]

Somewhere I read that all of the commands should have Guid, but as far as I can tell, this is not required.

Do I need to declare one on the main class deriving from Rhino.Plugins.PlugIn?

From what I can tell, installing the plugin then adds some/all of these Guids to the registry. Other issues I have had, but typically manage to work around, are what to do if I need to move a plugin install. Usually I would disable the plugin in the plugin manager, and then reinstall from the new location. Under rhino 7, something seems to be hanging this up, as any attempt to reinstall, even after manually cleaning the registry, seems to give the “ID in use” error.

Bonus points, maybe I should write an “uninstaller”… but I need to know all of the keys to remove, etc. I would also add, I would be willing to use the new package manager if it affects any of this, but my plugin also distributes with a large number of 3dm files, hundreds of Mb, so I would need to work around that.

For now I just need to figure out why I seem to only get one session of use and then something goes wrong.


The primary issue is the same as

Deleting the dll of the same name in the folder along with the rhp file fixes the issue. Any further thoughts are appreciated though.

If you have both an .rhp and a .dll with otherwise the same name, then please remove the one with .dll in the name.

So the reason the dll is there, is that in VS when you have cross-project dependencies, that is the easiest way to reference. I tried making a post build event to rename the dll (and then added a reference to the renamed dll). It seems rhino still found it, as the plugin stopped working. I guess I am going to try to use the post build to relocate the dll to a parent folder and reference it there.

A better approach is to move shared code into it’s own assembly so it can be referenced by multiple projects.

– Dale

That is a valid point. For now I changed the post build. The other assembly is “dependent” on this one regardless, so it seemed to be extra abstraction to separate out to being a class library, as opposed to a plugin.

If you edit the csproj file manually to replace the .dll extension with .rhp, then it should work fine. It’s just Visual Studio that doesn’t let you add a reference to an assembly that doesn’t have the .dll extension.