Yak issue switching versions

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.

– cs

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? :blush:

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

1 Like

Hey @Gijs , did you get a chance to ask @will? :slight_smile:

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.

1 Like

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.

I’ve added RH-72688 Yak issues updating plugins

1 Like

Could there be an option in the package to automatically purge old versions of the plugin?
This issue persists and it is pretty straight forward to install anew any older versions if required.

Still having this issue, it’s quite a pain for users. Are there any logs that could be checked so I can see if it’s an issue on our end in terms of permissions etc?

I also continue to get more emails with users having this issue.

It seems to be spreading: I just talked to a couple of coworkers yesterday who mentioned “oh yeah, the Package Manager doesn’t work for me either so I always have to close and go to AppData to manually clear it out first”

I recently installed GeometryGym and can confirm I got this same issue with GeometryGym as well as our internal software

1 Like

This problem seems to be increasing in frequency with many users reporting it. Is there any suggestions on how to avoid this when plugin updates?

Hey @jonm,

This has been fixed in Rhino 8 and we don’t currently have plans to backport a fix to 7.x as far as I’m aware. But if it’s causing a lot of issues we might be able to figure out a workaround.

If you have users reporting it in 8.x would you be able to get us a SystemInfo from them?

I continue to receive this error in Rhino 8, when i install the gg tools using the package manager.
The error for the gg tools is: Unable to load ggRhinoSPACEGASS.rhp plug-in: ID already in use.

Also receive the following error in rhino command:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.InteropServices, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime.InteropServices, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at System.ModuleHandle.ResolveType(RuntimeModule module, Int32 typeToken, IntPtr* typeInstArgs, Int32 typeInstCount, IntPtr* methodInstArgs, Int32 methodInstCount, ObjectHandleOnStack type)
   at System.ModuleHandle.ResolveTypeHandleInternal(RuntimeModule module, Int32 typeToken, RuntimeTypeHandle[] typeInstantiationContext, RuntimeTypeHandle[] methodInstantiationContext)
   at System.Reflection.RuntimeModule.ResolveType(Int32 metadataToken, Type[] genericTypeArguments, Type[] genericMethodArguments)
   at System.Reflection.CustomAttribute.FilterCustomAttributeRecord(CustomAttributeRecord caRecord, MetadataImport scope, Assembly& lastAptcaOkAssembly, RuntimeModule decoratedModule, MetadataToken decoratedToken, RuntimeType attributeFilterType, Boolean mustBeInheritable, Object[] attributes, IList derivedAttributes, RuntimeType& attributeType, IRuntimeMethodInfo& ctor, Boolean& ctorHasParameters, Boolean& isVarArg)
   at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeModule decoratedModule, Int32 decoratedMetadataToken, Int32 pcaCount, RuntimeType attributeFilterType, Boolean mustBeInheritable, IList derivedAttributes, Boolean isDecoratedTargetSecurityTransparent)
   at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeAssembly assembly, RuntimeType caType)
   at Rhino.Runtime.HostUtils.CreatePlugIn(Type pluginType, Assembly pluginAssembly, Boolean printDebugMessages, Boolean useRhinoDotNet)
   at Rhino.PlugIns.PlugIn.CreateFromAssembly(Assembly pluginAssembly, Boolean displayDebugInfo, Boolean useRhinoDotNet)
 
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Morning @user1489,

I’ve chatted with Jon and managed to replicate this issue, there is a ticket currently open RH-84141 (Not publicly viewable) which has this issue logged for Rhino 8.

In the meantime you can workaround this issue by uninstalling ggIFC first (try the Package Manager, and if that doesn’t work for you, you can remove it manually from AppData), restarting Rhino and then installing it fresh. I understand this isn’t an ideal workaround which I do apologise for, but it should enough to let you get your work done.

I am experiencing this issue in Rhino 8 as well. Commenting here to follow thread in anticipation of updates.

What version of Rhino are you running @ksteinfeld