Grasshopper Developer Settings

As a test to see if I can bypass the default roaming Gh library directories I've used Gh Developer settings to have Grasshopper look into additional locations which I've placed into the Grasshopper Program Files location.

My first question is where are these file paths being stored? Can I edit them directly via an XML file?

Question #2 is: Am I overlooking anything fundamental by doing this? (Will something go wrong later on to cause deep, deep regret on my part?)

Final question: If I wanted to get rid of the roaming data entirely and store everything within Program Files, can I modify an XML file to stop Grasshopper from auto-generating the Libraries and UserObjects folders, kernel, menu shortcuts, and ribbon XMLs, and versioning TXTs?

Thanks for any tips. Just exploring alternative installation options to see if I can keep all files out of Users and place them into Program Files.

Replies to This Discussion

Permalink Reply by Brian Ringley on July 14, 2014 at 11:25am

Well to answer my own question #2 if a developer writes a dll reference into their gha that relies upon the default roaming directory that's a problem.

Permalink Reply by Brian Ringley on July 14, 2014 at 11:46am

aaaaaaand another answer to question #2 which is when a developer writes the gha/dll directories into the rhp as is the case w/rhinoBIM, so no matter how many times you move or delete the rhinoBIM gha/dll files they will be regenerated upon the next launch of the rhinoBIM plugin within rhino.

Permalink Reply by David Rutten on July 14, 2014 at 11:52am

DO NOT put anything into the Grasshopper Program Files folder. It will get nuked whenever an update is installed.

DO NOT edit the Xml by hand or using an installer, it's difficult to get right, easy to do wrong and easy for someone else to screw you over.

DO install your GHA files using an RHI installer if at all possible. I know RHI doesn't yet work for GHA only (it also needs an RHP), which is super annoying, but whenever we have some spare time we'll start with that.

If you need to use a custom installer and need to make Grasshopper aware of the special location of your GHA file(s), put a *.ghlink file into the %AppData% grasshopper components folder which contains a line of text with the actual location for your GHA.

David Rutten

david@mcneel.com

Permalink Reply by Brian Ringley on July 14, 2014 at 12:12pm

Thanks David! I know you've fielded this question multiple times in the past - just wanted to make sure I understood the current state of things. This is very clear.

Permalink Reply by Brian Ringley on July 15, 2014 at 1:27pm

I just found this little gem for silently installing RHI for all users to C:\Program Files\Common Files.

So yes, whenever it's possible to make RHI for GHA only, this would allow for all GHAs to live in the Common directory.

The *.ghlink works great but has a few downsides that would make me want to just keep the component library where it is by default:

It doesn't work for user objects (much like you can't add an additional user object folder within the Grasshopper Developer Settings window)
Certain GHA files reference DLL files at the default component library directory (Geco) meaning that the user can't move that file without causing a load error
Certain RHP files auto-generate GHA files into the default component library directory (RhinoBIM) meaning the user will always have a file conflict

Points 2 and 3 being anomalous conditions is all the more reason for all developers to eventually migrate to RHI.

Permalink Reply by Jeroen Janssen on October 22, 2014 at 7:43am

To follow up on this discussion, how do these paths occur in the loaded folders, and how can we remove one? Currently Grasshopper tries to load assemblies from a network drive (\\akt08 in the screenshot). Therefore it it takes 10 mins to load Grasshopper, even before the start up screen and then finds one file ID conflict. It would be great to be able to edit these load locations somewhere.

Thanks!

Jeroen

Permalink Reply by David Rutten on October 22, 2014 at 8:54am

Those folders are probably considered by Rhino to be plugin load folders. If Rhino considers a folder to be associated with a plugin, then so does Grasshopper.

Can you confirm there's an RHP in that folder?

Permalink Reply by Jeroen Janssen on October 22, 2014 at 10:12am

Thanks David.

It's the folder IT here uses to store all the Rhino plugins necessary to install on our office pc's, so yes, there are several .gha files, Grasshopper itself, paneling tools and so fort.

Are they being assigned when an install is run directly from that location? Assuming this I guess we need to de-install all the plugins and then re-install them from the local machine?

Permalink Reply by David Rutten on October 22, 2014 at 10:50am

Yes, Grasshopper asks Rhino what folders might be interesting to look at, and any folder that was registered by a plugin installer falls into this category.

It is in general a bad idea to load dlls over a network, so if you can get IT to install stuff on a local machine that would be beneficial.

I do hope to be able to make remote loading better in GH2, basically by storing a description of each GHA locally and only actually loading the GHA for real the first time a component is used. But that functionality is nowhere near done, let alone available.

Permalink Reply by Jeroen Janssen on October 25, 2014 at 12:49pm

Thanks David,

we removed the installation files for the plugins from that specific network folder and that seems to solve the problem of loading from the network. The folder location is not in the list anymore and there are no duplicate assemblies anymore.

Permalink Reply by Eduardo on April 4, 2019 at 3:29am