Yak Installed Plugin path for Grasshopper Script components

Grasshopper
1

Hi,

At Geometry Gym, We’ve switched to Yak as the primary way to deploy our plugins, and the response so far has been very positive from both developer and user perspective.
But I’ve identified an aspect that isn’t ideal, and would suggest it might be improved if others agree.
When using a .msi, we could control the plugin path to a constant location such as C:\Program Files\Geometry Gym\Rhino7
When a user ran a newer version installer, the files would be updated and any references preserved.
However, when using Yak, the assembly path includes the version number, and this will change from build to build. Ie C:\Users\JonMirtschin\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\ggRhinoIFC\2.1.34.0

This is a problem when referencing an assembly in a grasshopper script component such as c#. This suggestion might not be practical, but it would be nice if the assembly is stored/resolved by it’s GUID if detected in a yak installation path. This isn’t just for version, the username is now in the path so if a script is shared between multiple users, the path will need to be revised when a different user opens the script.

210727 referenced assembly path
210727 referenced assembly path1370×729 90.7 KB

Let me know if this isn’t clear, and if there are ways of working around this that I haven’t identified.

Cheers,

Jon

2

We should allow for file names and use paths to components/plug-ins/framework to figure out which DLLs this corresponds to.

Added to our bug tracking system at
https://mcneel.myjetbrains.com/youtrack/issue/RH-65111

3

I just ran into this problem. A workaround I’m doing for now is:

  • Get all scripting components in the active Grasshopper canvas. You can do this by referencing ScriptComponents.gha and filter/cast components to Component_AbstractScript,
  • Check their assembly reference paths under component.ScriptSource.References. This is a list of strings with the full paths of the assemblies.
  • Check if any contains the assembly file name you are interested in, and if so, check if the path is valid.
  • Get the correct path where your Grasshopper plugin has been loaded from Grasshopper.Instances.ComponentServer.Libraries.
  • If it is, replace the path with the correct one in the component.ScriptSource.References list.

You can get away with not referencing ScriptComponents.gha by using reflection/dynamic.

I’m doing this on Instances.DocumentServer.DocumentAdded. Unfortunately the dialog box with the assembly not found message still shows up before that event is raised, but after closing it without correcting the path it works fine. Can’t figure out how to do this before that dialog box popups up.