How to define per-GHA loading mechanism?

I've recently discovered that for my new GHA plug in to work, it has to be loaded directly from disk rather than relying on COFF loading. Everything I've seen seems to indicate that I should be able to define a property of my assembly to tell GH to load it a specific way. My assumption was that I should just override the LoadingMechanism property of a class in my assembly implementing GH_AssemblyInfo, but unlike all the other properties, LoadingMechanism cannot be overridden.

What is the proper method by which to tell GH to load my GHA direct, independent of whole-app settings?

Replies to This Discussion

Permalink Reply by Andrew Heumann on January 24, 2015 at 11:34am

Yup - all Dlls unblocked.

Permalink Reply by David Rutten on January 26, 2015 at 7:19am

Well, I'm not getting anywhere quick. The assembly you posted has ForceDirect as a flag, but no matter what settings I pick for Grasshopper application wide loading scheme or if I override the loading of Human via the Preferences, it seems to work all the time.

Can you confirm that the required dlls are in fact in the same folder as the HumanUI.gha file that gets loaded? The GHA should be locked while Grasshopper is running (you shouldn't be able to rename or delete it), in case you need to make sure you've got the right one.

Permalink Reply by Andrew Heumann on January 26, 2015 at 7:28am

When you say it works all the time - you mean the launch window component functions without error? Or you're able to reproduce the issue I was having?

And to answer your question (if I understand correctly) - when I'm running (with COFF loading off entirely for all plugins) I'm unable to delete HumanUI.gha or any of its associated Dlls. With COFF loading enabled (left to each component/preferences to decide) I AM able to delete the GHA, despite the "forcedirect" flag. It's as though the flag is being ignored entirely.

Permalink Reply by David Rutten on January 26, 2015 at 9:54am

I don't get any errors while loading the GHA nor while adding any of the (iconless) components to the canvas.

Permalink Reply by David Rutten on January 26, 2015 at 10:00am

It's as though the flag is being ignored entirely.

Ah indeed. With _GrasshopperDeveloperSettings Memory Load option enabled and the load mechanism set to Plugin Default, the plugin doesn't win. That's clearly a bug.

However I can still can't make it fail either way. Do I have to do anything else beyond just dropping a few of those components onto the canvas?

Permalink Reply by Andrew Heumann on January 26, 2015 at 10:49am

The main component that fails is "launch window" - try setting the first parameter to true. If it's working a WPF dialog will appear on screen.

Permalink Reply by David Rutten on January 26, 2015 at 1:43pm

I presume this is the error then...

And I understand the problem now I think. We (McNeel) don't look for exe files when resolving references. Only libraries (dll, rhp, gha).

The system clearly does look for exe files, which is why it works if the gha is loaded from the disk, because then it's the system finding the assembly.

It is uncommon for code to reference an executable, especially if you write the exe there's no reason at all to go down this road. See the first answer to this post for some reason why it's a bad idea.

I'm uncomfortable making a change to RhinoCommon so it starts to resolve exes as well. I'll need to talk to Steve about that, but I'd rather we didn't do it at all.

If you really, really want to reference an exe, maybe you should handle the AssemblyResolve event yourself. Further info.

Permalink Reply by Vicente Soler on July 7, 2017 at 9:14am

Ah indeed. With _GrasshopperDeveloperSettings Memory Load option enabled and the load mechanism set to Plugin Default, the plugin doesn't win. That's clearly a bug.

Was this bug ever fixed? I'm running into the same issue.

Permalink Reply by Andrew Heumann on January 26, 2015 at 5:33pm

Thanks for chasing this down so relentlessly. I will try to figure out how to refactor the code I need into a dll before I go down the route of resolving the assembly myself. I'm relying on the visual studio WPF app template, which nicely handles translating xaml into c# code for execution - my previous tries at creating a DLL instead of an exe didn't bear fruit but I should probably revisit it. Again - greatly appreciate all your help working through this!!!

Permalink Reply by Andrew Heumann on January 26, 2015 at 7:16pm

Success! Recompiling as a DLL did the trick. A thousand thanks.

Permalink Reply by David Rutten on January 27, 2015 at 1:49am

Great!

Permalink Reply by Andrew Heumann on January 24, 2015 at 3:20am

Bump - David, can you clarify?