Time to test your plugins with Rhino 8!

Hi Rhino Developers, it’s time to test your plugins with Rhino 8 if you haven’t already!

In particular, the move to .NET 7 is an enormous change which might trip up some existing plugins, which means some plugins might need a few tweaks to work. The benefit can be huge, .NET 7 provides much better performance in a lot of scenarios and we’re now using the exact same runtime on both Windows and Mac.

We’ve collated some important information that you might need to know regarding Rhino 8 and the move to .NET 7. In particular, debugging in .NET 7 will require a few extra steps to get your projects set up.

Please let us know if you run into any troubles, and we’d be glad to help get your plugins working great in Rhino 8.


Hi @curtisw,

thanks for offering your help.

I was trying our plug-in with Rhino 8 and my experiences are the following:

  1. Targeting .NET 4.8: I basically just changed the launch program to Rhino 8 and it generally worked. Have still some issues with an SQLite database I’m using (SQLite error in Rhino 8 with .NET 4.8), the rest seems to work so far.

  2. Targeting .NET 7: I ran the Upgrade assistant you recommended at the dev conference and ran into quite some troubles:

  • Dependent libraries (e.g. Nuget dlls) aren’t copied to the output directory anymore and so the plug-in crashes during startup because of the missing libraries. Using <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> in the project file copies the libraries to the output, but now the plug-in doesn’t load anymore at all, I just get the generic “Unable to load plug-in: initialization failed” message from Rhino without any further information. <= this prevents me from using the plug-in with .NET 7 atm.
  • AssemblyInfo.cs will get removed and is then auto-generated during the build. However, I wasn’t able to set the plug-in GUI in the project file, so it was missing in the auto-generated assembly info file and Rhino therefore couldn’t load the plug-in’s panel when registering it like so in the PlugIn derived class, as this.Id is null:
Panels.RegisterPanel(this, panelType, "MyName", MyLogo, PanelType.System);
  • I then switched back to using the old AssemblyInfo.cs and removed the auto-generation, which seems to help. Do you know of a way to set the project GUID in the csproj file?
  • Some references like RhinoWindows were removed during the upgrade for some reason and I had to add them back manually
  • Some minor tweaks seem to be needed like adding <UseWindowsForms>true</UseWindowsForms> to the project file.
  • A Windows-only plug-in like ours uses some Windows-only methods which will all be marked with a warning unless one specifies net7.0-windows as the build target specifically and adds <GenerateAssemblyInfo>true</GenerateAssemblyInfo>
  • The RhinoCommon, RhinoWindows and Grasshopper references have those yellow warning signs stating “Package ‘RhinoCommon 7.29.23107.3001’ was restored using ‘.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1’ instead of the project target framework ‘net7.0-windows’. This package may not be fully compatible with your project.” Not sure if this is an issue or not.

Hey @ThomasM,
Regarding putting the GUID into the .csproj, you can add this line into your .csproj

<!-- Rhino Assembly Attributes -->
        <AssemblyAttribute Include="System.Runtime.InteropServices.GuidAttribute">

It’s also theoretically possible to add the other attributes in there, but when I tried, only a few types were supported and even explicitly stating the type fails for me

        <AssemblyAttribute Include="Rhino.PlugIns.PlugInDescriptionAttribute"
            _Parameter1="Is Rhino.PlugIns.DescriptionType.Country"
            _Parameter2="The Moon, Space"/>
1 Like

Great, that worked. Thanks!