YAK - Problem with referencing DLLs in different package versions

Rhino Developer Yak
1

Dear all,
I’m dealing with a Grasshopper plug-in that relies on native DLLs and .NET assemblies. All these dependencies are included in the YAK package, and everything works as expected—provided that only one version of the plug-in exists in the package folder.

However, when the plug-in is updated via YAK, the old version is not removed, and both the old and new versions remain side by side. This leads to inconsistent behavior: upon starting Rhino, the DLL versions loaded appear to be selected at random (as described in this post), which results in exceptions during startup.

It would be extremely helpful to have an option for loading DLLs specifically from the folder where the .gha file resides, or alternatively, the ability to define a manifest file to explicitly specify the versions to be used with the plug-in.

– Clemens

2

Hey @cp1, just to clarify, this is a single .gha plugin in a yak package and is not referencing anything outside of the yak package besides gh/rhino? If so this is a bug and needs fixing. Can I get some system info?

3

Hi @CallumSykes,
Yes, it’s a single .gha plugin. All the referenced DLLs are located in the same folder as the .gha file.

I believe I’ve found a workaround for the issue: you can create a class that derives from GH_AssemblyPriority and override the PriorityLoad() method. Inside this method, use SetDllDirectory(PathUtil.PluginPath()); to explicitly set the DLL search path, and then call a dummy method from the referenced DLL to ensure it’s loaded. Here, PathUtil.PluginPath() returns the path to the folder containing the .gha file.

That said, I’m not entirely sure if this will work in all cases. Since YAK retains older versions of the plugin, there might be scenarios where Grasshopper falls back to one of those. In such cases, the older versions might fail to run properly because Grasshopper loads the DLLs from the most recent version at startup when the above workaround is used.

– Clemens

1 Like
5

@cp1,

I could do with a little more info;

  1. Can I get a system info to attach to this ticket
  2. What is the GH Plug-in? Is it something I can find via yak or you may be able to send to us? If it needs to be private you can use Private Upload Tool

Ticket : RH-83489 Package Manager auto-update fails to fully uninstall old plugin

6

Hi @cp1, are you able to test this with the Rhino 8.22 release candidate?

This sounds similar to a bug that I recently fixed. We send both installed package version directories and loaded Rhino plug-in directories to Grasshopper. In some cases (e.g. after an update) this could cause Grasshopper to see two different versions of a package leading to plug-in loading conflicts. In Rhino 8.22 we de-duplicate the list (prioritising the version already loaded in Rhino).

1 Like
7

Hi @Will,
I’ve updated to Rhino 8.22, but the issue still occurs—though it seems to happen less frequently now.

I found that I had some older versions of the plug-in stored in C:\Program Files\Rhino 7\Plug-ins and C:\Program Files\Rhino 6\Plug-ins. After deleting those, the issue seemed to appear even less often.

What’s strange is that some users experience no issues at all with the plug-in, while others encounter them consistently.

To reproduce the problem on my machine, I had to follow these steps:

  • Disable the automatic update option in Rhino 8
  • Install Karamba3D 2.2.0.180
  • Restart Rhino → Karamba3D loads and works correctly
  • Install Karamba3D 3.1.50707
  • Restart Rhino → Roughly 1 in 10 times, Karamba3D fails to load, showing an error that karambafeb.dll could not be loaded or is the wrong version.

– Clemens

8

Thanks for the update, @cp1, and for testing with 8.22. I’ll try your steps to reproduce and hopefully I can catch it in the act!

9

RH-85306 is fixed in Rhino 8 Service Release 23