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 22, 2015 at 10:35am

error: 'HumanUI.HumanUI_AssemblyInfo.LoadingMechanism.get': cannot override inherited member 'Grasshopper.Kernel.GH_AssemblyInfo.LoadingMechanism.get' because it is not marked virtual, abstract, or override C:\Users\Andheum\Documents\Visual Studio 2013\Projects\HumanUI\HumanUI\HumanUI_AssemblyInfo.cs 27 13 HumanUI

Permalink Reply by David Rutten on January 22, 2015 at 10:53am

You have to put it as an assembly attribute. Obviously it cannot be part of the code, as I need to know how to load the assembly before I load the assembly.

Put this somewhere out in the open:

[assembly: Grasshopper.Kernel.GH_Loading(GH_LoadingDemand.XXXXXX)]

Permalink Reply by Andrew Heumann on January 22, 2015 at 11:40am

Awesome! Thanks.

Permalink Reply by Andrew Heumann on January 22, 2015 at 2:10pm

Sorry to be a bit thick, but can you elaborate on where "somewhere out in the open" might be? I tried putting "[assembly: GH_Loading(GH_LoadingDemand.ForceDirect)]" in my component's Properties/AssemblyInfo.cs along with all the other similar-looking [assembly: ...] statements, but it doesn't seem to work. Does it have to live 100% separate from my GHA altogether?

Permalink Reply by David Rutten on January 24, 2015 at 4:04am

It should be where you said you put it. This is where I put one for testing purposes:

Permalink Reply by Andrew Heumann on January 24, 2015 at 8:25am

Behavior is still strange. When in GrasshopperDeveloperSettings, I uncheck "enable COFF loading," everything functions fine. When I re-check that toggle and load, even with [assembly: GH_Loading(GH_LoadingDemand.ForceDirect)] in my assembly, certain components fail with the messages:

1. Before Solution exception:Could not load file or assembly 'HumanUIBaseApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

2. Solution exception:Could not load file or assembly 'HumanUIBaseApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

Even when I manually go into the grasshopper settings and force my GHA to load direct from disk, the error persists. The ONLY way it works is if I disable COFF loading for all components. What am I missing?

Permalink Reply by David Rutten on January 24, 2015 at 9:29am

This whole loading thing is a mess, but here's how it works at present:

Grasshopper allows users to set the loading mechanism per plugin. This setting takes precedence over all others. One way to access this setting is via the plugin properties in the About banner:
If the setting is 'Force Direct' the plugin will be loaded off the disk.
If the setting is 'Force COFF' the plugin is loaded via the memory.
If the setting is 'Grasshopper Default' (and the plugin does not have a loading assembly attribute) the setting in GrasshopperDeveloperSettings is used.
If the setting is 'Plugin Default' then the assembly attribute is located and obeyed, if the attribute cannot be found the Grasshopper Default is used.

For cases 4 and 5, if the assembly attribute has been defined but has been set to GH_LoadingDemand.Default, the Grasshopper default is used as well.

(second response to follow)

Permalink Reply by Andrew Heumann on January 24, 2015 at 10:00am

Just to clarify my current situation: I have tried setting the plugin to load as "Force Direct" as above, as well as left it at "Plugin Default," hoping that the [assembly...] statement will take care of forcing direct loading. However, in spite of this it doesn't work unless I disable the GrasshopperDeveloperSettings "Enable COFF loading," which I assume applies to all components.

Permalink Reply by David Rutten on January 24, 2015 at 9:33am

The "The system cannot find the file specified." error is because an assembly which is being executed requires another assembly which cannot be found/loaded.

When assemblies are loaded from the disk the system will look at other dll files near it. However when assemblies are loaded via memory then this mechanism doesn't know where to start looking.

Rhino handles a framework event for missing assemblies, because Rhino knows a few places worth looking the system doesn't (i.e. plugin folders). Grasshopper should be informing Rhino about these folders, but it seems something is amiss here.

Either GH is not telling Rhino vital information, or Rhino fails to find the correct assembly, despite knowing where to look.

Can you show me the exact layout of files as they're on the disk? Also, I could help out a lot better if I could replicate the problem here. Where do I get the files needed to reproduce this and what do I need to do?

Permalink Reply by Andrew Heumann on January 24, 2015 at 9:57am

Here's the .gha and associated dependencies. Do you want the source to muck around with as well or does reflection suffice? https://www.dropbox.com/s/mksm2943uc58vx7/HumanUI.zip?dl=0

Permalink Reply by Andrew Heumann on January 24, 2015 at 10:02am

I've got all the packaged dependencies set to "Copy Local" when I compile, and I'm putting them directly in the C:/users/whatever/appdata/roaming/Grasshopper/Libraries folder along with the .GHA.

Permalink Reply by David Rutten on January 24, 2015 at 11:28am

Ok got it, I'll test after dinner.

Just to make sure in the meantime, the dlls etc. are all unblocked right?