Access Rhino PlugIn Problems "Memory load *.GHA assemblys in Coff byte arrays"

Replies to This Discussion

Permalink Reply by David Rutten on February 18, 2017 at 5:25pm

Is there a way to circumvent unchecking this option or another way to call the object? 

I don't understand. The user checks or unchecks the option, you can't circumvent that. However you can override the load mechanism of individual GHA plugins via the Grasshopper preferences. It is also possible to add a load mechanism indicator to a GHA plugin (as an assembly attribute) which will be detected by Grasshopper prior to loading the plugin.

I'm a bit fuzzy about the problem you're having. Does your GHA project reference an RHP dll?

Permalink Reply by philippL on February 19, 2017 at 1:25pm

hey david, thanks for getting back to me so quickly!

Does your GHA project reference an RHP dll?

ok, I try to explain in more detail, what Im doing :) 
I am extending a VS Project (C#) containing the PlugIn Code with GH components (all in one namespace). I am trying to set up the GH components to act as alternative user-interface to the PlugIn Code. So both use same classes/functions.
In the end I am building a .dll which is renamed to .rhp and .gha. The Rhino PlugInManager is loading the .rhp, GH is loading the .gha lib. 
Im afraid I am not deep enough into scripting so far, so do they reference each other? I thought they have the same capabilities, just with different user-interfaces (please correct me if I m completely wrong in understanding things...).

The PlugIn Code was set up first and a lot of data (input by user) is stored as 
property of the PlugIn Object (derived from Rhino.PlugIns.PlugIn). 
When Rhino is opened, the PlugIn is loaded, so a PlugIn Object exists. And if I uncheck "Memory load *.GHA..." this object can be found and 
access to its properties is allowed. If it is checked, no PlugIn object is found.

Permalink Reply by David Rutten on February 19, 2017 at 1:52pm

That may be a problem. If you are trying to load the same assembly twice, it'll just return the already loaded one the second time. It doesn't really matter that the file has a different extension. Ideally there'd be a dll which contains all the important code, and then an RHP project which references that dll and provides thin command wrappers for the functionality, and a GHA project which also references the same dll and which provides thin component wrappers for the functionality.

If the two assemblies are not entirely the same (maybe you've set up some build flavours so that sometimes it builds Command classes and sometimes GH_Component classes?), then it shouldn't be an issue.

If Grasshopper loads a GHA, it also certainly won't look for and initialise any Plugin object.

If you're telling Grasshopper to load the dll through a COFF buffer rather than directly from the disk, then it will load the exact dll you've specified, it won't try to be clever about which dlls to load. So in that case you'll get a double load of the 'same' dll, but with the second one not having its Plugin object initialised.

I recommend either setting up build flavours with some #ifdef conditionals, or breaking up the project into 3; one dll with all the functionality, one rhp with only commands, and a gha with only components.

Permalink Reply by philippL on February 24, 2017 at 1:41am

Thanks david! Its working perfectly fine with breaking the project to 3 parts! :)

Permalink Reply by David Rutten on February 24, 2017 at 2:49am

Glad it worked out!