algorithmic modeling for Rhino

Dear GHA developers,

Hopefully in a few days Grasshopper 0.9.0050 will be released. The last two hurdles (the installer and assembly version rolling) are now working so once I'm certain there are no other serious bugs we're good to go.

Although there are plenty of potentially breaking changes to the SDK, I'm boldly assuming that (almost) none of them will affect your typical GHA library. If this is not the case I'll do my best to try and add some legacy support for features that have changed soon after the initial release.

There are however a few new things that you probably should support. In this discussion I'll outline several of them. Some of these are already in the current release.

Views: 4542

Replies to This Discussion

Before/After Solution

It is now easier to do stuff before and after any calls to SolveInstance during a single solution. There are two overridable methods on GH_Component called:

  • BeforeSolveInstance()
  • AfterSolveInstance()

You no longer have to look at the DA.Iteration field and you no longer have to guess which call to SolveInstance is the last one.


David Rutten

Poprad, Slovakia

I am dying for using the new version. awaiting .....

Component Keywords

It is now possible to override the Keywords property on all IGH_DocumentObject derived classes (like components and parameters). Return a collection (List, Array I don't care) of strings that will be traversed when searching for objects in the double-click-on-canvas pop-up window.

For example the [Curve CP] component is now actually called [Curve Closest Point] and the Keywords property on it looks like:

public override IEnumerable<string> Keywords
    return new string[] { "CP", "Nearest" };

because searching also works on partial hits so if people search for "near" it will be covered by "nearest".


David Rutten

Poprad, Slovakia

David any idea when we can expect this release? I suspect i have to rewrite a lot of code.

What sort of code do you expect will go stale?

Although there are breakages to the SDK, if a certain function no longer works then I can always try and put it back in for legacy purposes.


David Rutten

Poprad, Slovakia

Loading GHA files

A new way of loading non-standard GHA files has been added to make it easier to install 3rd party GH plugins. In addition to putting a GHA file into the %ApplicationData%\Grasshopper\Libraries\ and changing the core xml settings to add a custom load path, a *.ghlink file can now be put in the appdata folder with any number of absolute paths.

GHLINK files are just standard text files with the following rules:

  • File extension must be *.ghlink
  • Whitespace at the start and end of every line in the file is ignored.
  • Lines starting with # are ignored.
  • Lines starting with // are ignored.
  • Lines containing valid folder paths are parsed and the folder indicated will be traversed for GHA files. Subfolders will not be included in the search.

So for example, let's say we've written a Rhino plugin project called Fruitbat which includes a FruitbatComponents.gha file. Since it's not just a Grasshopper plugin, we don't want to put it the %ApplicationData%\Grasshopper\Libraries\ folder. Instead, our installer will put all the associated files of this project in C:\Program Files\AwesomeSoftwareCorp\Fruitbat\

In order to get GH to load FruitbatComponents.gha, we need to add a text file at %ApplicationData%\Grasshopper\Libraries\Fruitbat.ghlink with the content:

#Link to Fruitbat components

C:\Program Files\AwesomeSoftwareCorp\Fruitbat\



David Rutten

Poprad, Slovakia

Is 0.9.0050 compiled on NET 3.5 or NET 4.0?  I am wondering for coding c# component libraries in Visal Studio - can I switch to NET 4.0 now?


4.0    Rhino5 requires a minimum of .NET 4.0 so I upgraded.


David Rutten

Poprad, Slovakia

Excellent timing.  Thank you.


Just FYI I have been working in c# on a component library with a 3rd party .NET dll using 3.5 NET.  After this thread I switched to 4.0 and get an error about not being able to load the Assembly and Exception from HRESULT: 0x80131044

I switched back to using / referencing the 3.5 NET dll and everything works fine.  If there's any possible explanation I am interested.

Seems like the problem is strongly named assemblies (or lack thereof). Is this of any help? 


David Rutten

Poprad, Slovakia

No, it's not actually that, though the error messages often mention Strong Name Assemblies (even when the problem is dependent dlls being x86 instead of 64-bit).  I verified with the Developer Command Prompt in VS that both the 3.5 and 4.0 NET dlls are Strong Named. 






  • Add Photos
  • View All

© 2021   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service