I have several Rhino 5 plugins that result in load errors after installing Rhino WIP. See below for an example.
Its properties show that it’s using Rhino WIP to boot. My manually pointing it to the Rhino 5 EXE doesn’t seem to do anything as far as how the plugin reads the file—it understands all Rhino.exe files as “Rhino WIP,” regardless of directory.
What makes sense is the plugin loads and works in Rhino 5 (after I point it to the proper EXE). But I’m not sure how to avoid receiving this error with every load.
The issue is more complicated than you realize.
Plug-ins for a specific version of Rhino have to be based on the Software Development Kit for that build of Rhino.
Rhino V6 (WIP) does not yet have a “frozen” SDK. That means that every time we release a new WIP, the SDK has changed so any existing plug-in based on an older (last week’s) SDK will be broken and not load.
We do make our SDKs available to developers like Chaos Group but a public release of a plug-in is a waste of time because by the time they tweak, compile, and release a beta plug-in, we have released a new WIP just a week later.
Do yourself a favor and don’t mess with any WIP plug-ins until you hear that the SDK has been frozen. Then there will be time to actually try one out. Even after freezing the SDK, we may have to break it again with additions for features we’re working on.
When a public announcement is made that the SDK has been frozen, that means we don’t think any more changes will need to be made before product version release, and that we are closing in on releasing a new version of Rhino.
I thought it had something to do with the different SDKs.
For the record, I’m not playing with WIP plugins; these are Rhino 5 plugins.
Thanks for the clarification, John.
FWIW,
I’ve just tried this function with some other plug-in (granted, not installed for RH5) and that worked. The plug-in wasn’t loaded on next launch.
You wrote that you have several plug-ins that do this. Are they from different suppliers?
