Rhino 9 Grasshopper Plugin Migration

Grasshopper Developer
, , ,
1

Hello everyone,

Does anyone know of a migration guide for moving Grasshopper plugins from version 8 to 9?

Are there any known pitfalls or important changes to be aware of when upgrading to the new version?

Thanks in advance for any guidance.
Best.

2 Likes
2

Hi,

Honestly, I haven’t fully figured it out myself yet. Something might have changed in Grasshopper in Rhino 9, but there’s just no clear official info on it yet. So it’s pretty hard to say upfront whether the plugin will work or not.

Couldn’t find any migration guide either. My guess is it just hasn’t been put out yet, Rhino 9 is still WIP, that kind of stuff usually comes later.

From what’s already known: Rhino 9 is moving to .NET 9. Rhino 8 used .NET 7/8, and in Rhino 9 WIP the default is NetCoreVersion=v9. So if your plugin was built against older versions, .NET 7/8 or especially Framework 4.8, compatibility issues are pretty likely.

There’s also a SetDotNetRuntime command that lets you switch between .NET versions inside Rhino. Worth trying if the plugin doesn’t start.

I’d start simple, just take the plugin as is and try running it in Rhino 9. Sometimes it just works. If not, then you can dig into what’s actually breaking.

If you get errors or the plugin won’t load at all, just note down what’s happening. At least then there’s something to go on, could be .NET, RhinoCommon, or something in the code itself.

Oh and moving from 7 to 8 some plugins needed tweaks too, 9 will probably be a similar story, just with the focus on the .NET 9 transition.

-Robert

2 Likes
3

Thank you for your reply. I tested it further in the meantime and also built a YAK package (rh9-any.yak ). So far it seems to work, and the Rhino 8 packages also worked in my tests.

When I run yak build , everything completes successfully. It produces the expected rh9_0-any.yak file, and the package loads correctly in Rhino 9 based on my testing.

The issue appears when running it in rhino.compute on Linux. In that environment, Rhino reports that the file is corrupted. That is why I wondered whether additional build configurations might be required for plugins that need to run across Windows, macOS, and Linux.

4

Ok, I figured it out.

Previously, I built the plugin as a multi-target project, similar to how I did it for Rhino 8:

  • net48
  • net7

In my latest tests, which also worked with rhino.compute on Linux, I instead built it like this:

<TargetFrameworks>net9.0</TargetFrameworks>

and used the following package reference:

<PackageReference Include="Grasshopper" Version="9.0.25266.10145-wip" ExcludeAssets="runtime"/>

For the YAK packaging, it also required a flat directory structure, for example:

  • icon.png
  • manifest.yml
  • Selva.gha

Running yak build in that directory produces selva-0.7.2-rh9_0-any.yak. With this flat structure, the package now loads correctly in rhino.compute 9 on Linux.

1 Like