Grasshopper

algorithmic modeling for Rhino

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?

Views: 3187

Reply to This

Replies to This Discussion

Yup - all Dlls unblocked.

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.

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. 

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

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?

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.

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.

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.

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!!!

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

Great!
Bump - David, can you clarify?

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2019   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service