Installing a Grasshopper plugin for Rhino 6 or Rhino 7 only

Is it possible to install a Grasshopper plugin such that it will only be loaded by Grasshopper in Rhino 6 or Rhino 7?
We would like to distribute different versions of our plugin for Rhino 6 and Rhino 7, because of new features available only for Rhino 7.


Hey @snabela, there are two ways that you could do this…

  1. Use the package manager!

    Each version of a package can have multiple “distributions”, where a distribution targets a specific platform and/or version of Rhino. When users search for your package, they’ll only be able to download versions which have distributions compatible with their platform and Rhino version. See the docs for more info and let me know if anything is unclear!

  2. Alternatively, check the Rhino version when your plug-in loads. Something like…

    public class MyAssemblyPriority : Grasshopper.Kernel.GH_AssemblyPriority
        public override GH_LoadingInstruction PriorityLoad()
            if (Rhino.RhinoApp.Version.Major == 7)
                return GH_LoadingInstruction.Proceed;
                // TODO: display message to user
                return GH_LoadingInstruction.Abort;
1 Like

Many thanks for this hint @will! We want to support parallel installations for Rhino 6 and Rhino 7, I guess this means we should choose option 2, did I understand this correctly?

Both options will work in this scenario. Packages are installed separately for each version of Rhino. If you look at the API entry for PanelingTools, you can see the different distributions for Rhino 6 and 7 –

The advantage of using the package manager here is that the compatibility is checked when the user tries to install the plug-in, rather than at runtime.

One disadvantage is that in Rhino 6 the package manager is hidden behind a test command (_TestPackageManager) and it uses an old version of the UI.

I have tried this option, but found that Grasshopper asks which plugin to load beforehand:


I am trying to achieve a setup where I can have two versions of the plugin installed: One that get’s loaded by Grasshopper in Rhino 6, another one that gets loaded by Grasshopper in Rhino 7. Is that possible at all?

Just tried what happens when renaming one of the plugins. The initial popup doesn’t show up as expected, but Rhino 6 will still try to load the version of the plugin which was built against Rhino 7, completely forgot about that :sweat_smile:

Seems like we are getting closer to a solution. Is there a way to configure plugins to be loaded from different locations for Rhino 6 and Rhino 7, e.g. by means of .ghlink files?

Ah, I didn’t consider the situation where you install both versions of the plug-in side-by-side for Rhino 6 and Rhino 7. This is possible with the package manager – the Rhino 6 version of the package will be installed to a separate location that’s only used by Rhino 6, and vice-versa for Rhino 7.

Is there anything that’s making you apprehensive about using the package manger?

We are finally going to give it a try :wink:
If I understood correctly it is possible now to include several Grasshopper and Rhino plugins into a single package, I wasn’t aware of this improvement, that’s what we need.

Out of curiosity: What are those directories that are only used by Rhino 6 or Rhino 7?

Yep, this was more a limitation of the packaging process and has now been removed. Make sure you’re using the version of the yak CLI tool that’s included with Rhino 7. That’s also the version that has all the new stuff to generate correctly named package files based on the version of RhinoCommon/Grasshopper used in your GHAs.

From the docs…

The filename includes a “distribution tag” (in this case rh6_18-any ). The first part, rh6_18 , is inferred from the version of Grasshopper.dll or Rhinocommon.dll that is referenced in the plug-in project. The second part, any , refers to the platform that the plug-in is intended for. To build a platform-specfic package, run the build command again with the --platform <platform> argument, where <platform> can be either win or mac .

It should just work if you’re referencing v6 and v7 RhinoCommon/Grasshopper respectively in the Rhino 6 and Rhino 7 versions of your plug-in. You should get two package files, e.g.

  • shapediver-1.0.0-rh6_18-any.yak
  • shapediver-1.0.0-rh7_0-any.yak

If you’re referencing RhinoCommon/Grasshopper v5 in the Rhino 6 version of your plug-in then you’ll get a package with rh5_* in the file name. Rename it to rh6_0, otherwise it won’t show up in the Package Manager for Rhino 6.

Also note that the spec command will use the first GHA that it finds when generating a manifest.yml file. You’ll likely need to edit this file afterwards to give the package a more general name and description.

Packages are installed to %appdata%\McNeel\Rhinoceros\packages.

Many thanks, that is very useful. One more question: For local development, is there another way to clearly separate which plugins get loaded by Grasshopper in Rhino 6 and Rhino 7?

type command line: grasshopperignoreplugin and select the gha files you don’t want to load in GH 4 RH6

BTW did you find a better way to manage GH plugins between different versions of RH?