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.
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
