I have a plugin which I deploy through yak.
The yak package contains 3 rhino plugins, and 1 grasshopper plugin.
When users try to switch versions using yak. They have issues with the larger plugin which we’ll call Alpha. Say they switch from v1 → v2. It seems that Rhino seems to have already referenced Alpha v1 and is unable to release it to reference v2. I cannot figure out why this.
Performing the install via the Yak CLI with Rhino closed works flawlessly.
Any help is appreciated as nothing appears in any log and I’m unable to figure out what is going on.
Do I understand correctly that only one of your plugins doesn’t update to a newer version through PackageManager, while the others do? Does it work when updating the plugin while in SafeMode?
Hey @Gijs that is correct yes.
1 package → 1 gh loads, 2 rhp load, 1 rhp fails to load after an update
I tried calling Rhino from the command line with a /safemode flag Rhino /safemode. If I upgraded or downgraded in this mode, then switched opened rhino it loads correctly. What does this tell us?
I also realised the other day that some other external yak packages have this issue, so I’m assuming its an us issue.
Well I think it tells me that while that plugin is loaded something prevents the installer to work as it should. I’m going to ask @will if he has a clue
Just as a note to add here, I get users report same experience with geometrygym plug-ins. Not frequently, and haven’t identied what might trigger the behaviour but I do get at least a couple of emails on month on this.
I have noticed same with my HSA. If my plugin panel was open during update, after restart Rhino still wants to load it before upgrade takes effect, preventing upgrade process. If my plugin panel is closed it is not happening.
My plugin panel is registered during OnLoad event.
When this happens to me, it’s because the registry value storing where the .rhp is doesn’t update to reflect the new version’s file path (which is different since each version is in a directory that includes the version’s name).
That is, \HKEY_CURRENT_USER\Software\McNeel\Rhinoceros\7.0\Plug-Ins[big long hash associated with the plugin]\PlugIn\FileName still uses the old version’s file path instead of the one for the version the user just tried to upgrade to.
If I manually update this entry, the plugin loads properly.
No clue why this registry entry isn’t updating for some plugins sometimes. I get this error all of the time, but other users don’t, even with the exact same plugins and general IT setups.
