my understanding is that depending on which version of Rhino I will open my Grasshopper file, it will then use this version of Rhino geometry kernel to run the Grasshopper file ← correct me if I’m wrong.
my goal would be to have an option to specify which Rhino version should be used for specific GH document. Or have an ability to easly switch between multiple Rhino versions inside Rhino.
Why I’m asking for this? Because without this any Grasshopper script can be vulnerable to any future Rhino kernel change. Also such switching of version could help with reproducing and debugging.
Grasshopper mostly call for Rhinocommon classes and methods.
Different Rhino Service Releases (SR) might update and/or fix bugs (or create new bugs, rarely), replacing the code in Rhinocommon libraries.
Currently each Rhino installation have a single library, not multiple.
If, for example, your code worked in 8.15, and an update to 8.17 broken something, your only solution is to revert, reinstalling the older version.
Storing every past version of every method would result in a huge installation size, and a mess to maintain.
If instead you are referring to main releases (7 , 8 , 9 , etc) … then indeed it’s a little bothering that the simple double-click will open your file ignoring the internal metadata.
I quickly open any external .gh file with Notepad++ and see the starting string to use the correct Rhino version to open it.
This can be said for .3dm files too.
I was thinking both about minor and major releases.
I guess I’m asking probably for too much, but generally in ideal scenario Grasshopper script could be isolated enough to be run on specific version of Rhinocommon. It’s like right now there are Grasshopper plugins with multiple versions: I can put a dll of specific version in a folder, and then this script will use this specific version of this plugin. I’d love to have such control with Rhinocommon library as well.
Currently once you have a Grasshopper script and you want to send it to your colleague: how to make sure he will get exactly the same results of the script once he open this script on his machine?
I’m generally happy with the Grasshopper stability though.
Ok, now you put the problem in a more interesting way, worth its own dedicated thread.
Personally I try to avoid plugins for exactly that reason.
You have to bring the plugin files in every machine, and if everything is good you still might have to restart Rhino once.
Often users do not have admin access to enable plugin files.
If you can get your plugins through PackageManager it’s better, but still limited to user permissions.
As you mentioned, putting the plugin files (.gha .dll) in \AppData\Roaming\Grasshopper\Libraries usually is enough to make your .gh “portable”, it’s a bit of a hassle but you can manage to set it up properly in a minute.
I did some script to encode .dll libraries into a huge chunk of text internalized in the .gh file, and whenever the .dll doesn’t exist the script itself create it decoding the text… you still need to restart Rhino, and the .gh finally increase in size by the size of the library.
Probably a bad practice…
Indeed, me too. Actual workflow-breaking bugs are rare.
Do you have an example where this is needed?
Overall it’s rare to see a working .gh script that behave differently in new Rhino SR/releases.
Keep your Rhino installer stored somewhere and zip your .gh together with the .gha/.dll needed for it to run.