Managing Grasshopper plugins with multiple Rhino versions installed

I have Rhino 5, 6, and 7 installed on my computer. When 8 is out of WIP and I upgrade, I will have that installed too.

I want to have my grasshopper plugins (and user objects, but one thing at a time) separated by Rhino version, so I can have a folder for GH plugins for R5 (that only load in R5), a folder for GH plugins for R6 (that only load in R6), and a folder for GH plugins for R7 (that only load in R7). Sounds reasonable, right? Turns out it is actually a nightmare that even phone support could not answer… @BrianJ @DavidRutten @will

I thought this would be easy to organize, since I know you can use .no6 dummy files to have plugins that only load in R5 and not R6. That works for that case, so I at least have a way to have R5-only plugins.

PROBLEM #1: .no6 files are also ignored by Rhino 7. Why? Not intuitive to the point it must be a bug. Why would a NO 6 file also work as a NO 7? I don’t have an answer and neither did McNeel support.

If I want to do the inverse, have a plugin that only loads in R6 and NOT R5, I must put it into the AppData\Roaming\Grasshopper\6\Libraries folder. And then it does not get loaded into R5. That is great. But here comes another issue…

PROBLEM #2: Rhino 7 also loads plugins from the AppData\Roaming\Grasshopper\6\Libraries folder. Why?? It is not intuitive to the point it also must be a bug. Why would R7 look into this folder for plugins, when this folder is specifically for hiding plugins from another version of Rhino? I don’t have an answer and neither did McNeel support.

Here is what support recommended me to try, which I greatly appreciated, but unfortunately neither proposed solution worked: They said to try dragging and dropping the .GHA files onto the GH canvas in each version of Rhino. It does not work for more than the current session; upon closing and reopening Rhino/GH the dragged-and-dropped plugins disappear. They said to try manually installing plugins to the package manager folders (AppData\Roaming\McNeel\Rhinoceros\Packages\6.0 or 7.0) This also did not work, but was a good idea, because seemingly at least these folders are truly separated by Rhino version.

Now here’s the final issue. The GrasshopperDeveloperSettings command can be used to point GH to a custom folder where you can put plugins. This could have been the answer, but…

PROBLEM #3: The GrasshopperDeveloperSettings command is SHARED between Rhino versions! Why? I wish I could just make custom folders for each installed Rhino version, and then open R5, use this command to point it to that folder, close R5, repeat with R6 and R7. But when I run the command in R6, I see the R5 folder I made! This means I cannot use this command for anything but plugins that should be shared across all installed Rhino versions, and if that’s the case, why shouldn’t I just put those plugins in the shared libraries folder AppData\Roaming\Grasshopper\Libraries ? Meaning the GrasshopperDeveloperSettings command is basically useless…

If there is a solution, I have not been able to find it on the forum. The most relevant thread ended without a solution and @stevebaer said a few times not to do what the users in that thread did as a workaround.

To sum up, there must be a singular, standardized way to organize plugins per Rhino version. It is totally confusing that there are different methods of doing this for R5 vs R6/R7, and with 8 coming, I hope this gets addressed.

In my opinion, all of this could easily be “fixed” if the GrasshopperDeveloperSettings command was NOT shared between versions. Then anyone who has multiple versions of Rhino could simply use this command to point each version to a specific user-created folder containing the GH plugins they want to use for each version of Rhino. I mean, what is the rationale for having that command shared between versions?

1 Like
  1. .no6 files are also utilized by Rhino 7
  2. Rhino 7 loads plugins inside the AppData\Roaming\Grasshopper\6\Libraries folder
  3. GrasshopperDeveloperSettings command is shared between Rhino versions
  4. All of this results in there not being a clear way to manage GH plugins between Rhino versions

Anyone? @BrianJ at McNeel support sent me here and told me to tag @DavidRutten & @will

Hi @jaymezd apologies for the delay. I’ve pinged some of the developers to try and find a viable approach to do what you’d like currently but none has been suggested yet. I’m filing to get this on the list and will also nudge the developers again in case they can offer more information to help with the current GH plugin system in regards to multiple versions of Rhino on a single machine.


One suggestion I got from chatting about this with the developers was to use virtual machines set up for the different Rhino versions installed. I haven’t tried this myself but it may prove easiest for controlling GH plugin loading currently.

1 Like

Thank you Brian! I appreciate the youtrack issue you filed. Virtual machines are something I had not considered. I’ll definitely have to look into that.

1 Like

@BrianJ I would like to add that some mechanism to transfer installation configurations between machines like pip freeze > requirements.txt would be a great addition to yak.

Or do I miss some functionality?

We would need this for

  1. Teaching: Getting specific configurations on student computers.
  2. Office: Office wide consistent machine setup

Thanks @silvano for the suggestion. @will Do you have any thoughts on this request if the plugins were found in the Package Manager?

1 Like

Hi Silvano -

I’ve added this request to RH-69828 (not visible to the public).


Sad to see that RH-69048 has been set to “won’t fix”…

In David’s reply on that page he mentions:

There’s already some mechanisms for specifying which version a plugin is for. The *.no6 file blocking trick for one.

Is it only the one .no6 trick, for not including a plugin in r6? Does anyone know some other mechanisms/tricks for doing this for R5, R6, and R7?

And how will Yak in GH2 handle this problem if I still have R5, R6, R7, etc installed?