Plugin fails in Rhino 8


We’re developing a plugin. It currently runs in Rhino 6 and 7.

We’ve compiled a version using the Rhino 8 RhinoCommon API.

The version compiled for Rhino 8 fails to load when starting Rhino 8.
Error message: System.Exception: No PlugIn subclass found.
at Rhino.PlugIns.PlugIn.CreateFromAssembly(Assembly pluginAssembly, Boolean displayDebugInfo, Boolean useRhinoDotNet)

Any ideas?

B&A Software AS

Are you starting Rhino with the /netfx switch? Or did you recompile the plugin for .Net Core.

If you are targeting .Net Framework 4.8, you need to start rhino with /netfx switch.

Thank you for the swift reply.
The project’s “Target framework” is .NET Framework 4.8.
How do I switch to .Net Core?
Will this break compatibility with Rhino 7?

Changing the target framework of your plugin can be pretty involved depending on what third party NuGet packages you may be using, and whether they support .Net Core. If you change your plugins framework, it will only run in Rhino 8+. .Net Core support was added in Rhino 8.

As I said, I recommend just adding the switch to the startup of Rhino.


Thank you for the illuminating answer.
The plugin will be running on our customers systems.
It’s my understanding that they then will have to add this switch to their Rhino 8.
Is there a way we could streamline usage of .NET framework 4.8 for them, and is this something we should do?

Hei Stig -
There is no “good” solution to this issue. Forcing your customers to use the switch might make other plug-ins on Rhino 8 not work. The best way is to provide both a framework 4.8 version for Rhino 7 and a Core version for Rhino 8.

I don’t recall the issue number- what’s the timeline for the update to the package manager allowing us to include both 4.8 and 7.0 in a single package so it “just works” regardless of which command line switch is used?

Our solution is to use an application launcher .exe. Our Startup.exe does the following either the first two, or these last two steps:

  • Starts an Update Installer

  • Restarts the Application

  • Validates our custom License

  • Launches Rhino with our Skin/Scheme/Plugin.

So our startup.exe knows if it is trying to run under Rhino 7 or Rhino 8. And if it is Rhino 8 then it applies the switch to the startup of Rhino. You could simply include two shortcuts for your application, one that is for Rhino 8 and the other for Rhino 7.

Either way, we feel using our own startup .exe gives us a lot more control over the PC, the installation, and helps customers troubleshoot if something is missing, out-of-date, or not installed.