Plug-in created with Script Editor won't run after last Rhino 8 update


I have created a plug-in through the new Script Editor Project Publisher. It was published to YAK (under the name “Jester”) and everything was fine since the previous update of Rhino 8.

Since then the plug-in’s functions don’t run at all. At first I had the message:

Project deserializiation failed

I updated it again today to the current last one (8.6.24086.11001, 2024-03-26). The functions still don’t run but the message is now:

Command: _jstrAliasBlock
System.Exception: No PlugIn subclass found.
   at Rhino.PlugIns.PlugIn.CreateFromAssembly(Assembly pluginAssembly, Boolean displayDebugInfo, Boolean useRhinoDotNet)

Uninstalling-reinstalling the plug-in makes no difference.

The python commands on which is based the plug-in run fine on their own through the Script Editor.

Any idea ?

What are the rhino versions before?

We have a breaking change between 8.5 and 8.6 in the way plugins load. Would you mind republishing your plugin and test to see if it loads?

Hi, thanks for you answer. I just republished it (0.0.2) and everything works fine now. Thanks !

1 Like

this sounds ominous – could you please say more about it, or point to a topic where it is detailed? I generally do not run or code against service release candidates, since they present too much of a moving target

Sure. The whole script publishing toolchain is still being improved and debugged so I didn’t think the change would break too many published scripts

However it was an important change for Rhino performance. Before this change, Rhino would load the scripting infrastructure during launch and it would make the launch a bit slower.

We decided to delay load the scripting infrastructure, only when scripting features e.g. ScriptEditor or Grasshopper Script Component is being used.

This created a complicated situation for plugins that are published by the script editor as they would need the scripting infrastructure to run.

The plugin previously published by @crtn-hrd would assume the scripting infrastructure is already loaded an ready. The new version that was published, does not have that assumption embedded in it and it ensures the scripting infrastructure is loaded before preparing the commands and components in the published plugin.

I hope this makes sense. Hopefully this is the last time I have to do breaking changes :smiley:



1 Like