I’m writing a plugin that depends on another plugin so the load order of plugins is quite important, I started a debug session in Visual Studio and referenced the list of modules, however I cannot discern what dictates the load order, it doesn’t seem to be by name, is it by GUID?
– Callum
It’s pretty much random, there’s so many aspects that may influence it that it’ll be hard to predict.
Does plugin B simply reference plugin A, or must A have been fully loaded first?
Plugin B references Plugin A. The Plugin A .gha file is loaded into the Plugin B Visual Studio project so that the namespace can be accessed by Plugin B, which means that Plugin A needs to be loaded first by Grasshopper for Plugin B to work.
Is it possible during the loading sequence for a plugin to request to be loaded later?
Why not move dependent code to it’s own assembly so that can be referenced by both plug-ins?
– Dale
I would if I could, but Plugin A is a 3rd party Plugin.
How are you using PlugIn A in your project? Is there an assembly reference?
Yes @stevebaer, the methods and classes required live inside of Plugin A.gha, so I referenced in the gha to Plugin B, which is a bit of a pain.
I guess we could sort load times based on if you are referencing a gha or rhp and load those last. I haven’t run into devs actually referencing these types of assemblies before. Did you manually adjust references in your csproj file?
Yeah I admit it’s a bit of an odd one. And yeah, I renamed the .gha to .dll, referenced that in, then re-renamed it from .dll back to .gha and changed the .csproj file to point to .gha rather than .dll. What a faff!
I’ve found other people trying to do the same thing to write custom Karamba Components:
It seems @jonm has solved this by doing the following:
However I don’t quite follow how this can be ensured, as @DavidRutten said, the loading is pretty much random.
Currently loading is pretty much random. I’m referring to making changes in a future service release. We can inspect assemblies to get a list of their dependencies. If a dependency exists that is another gha, then we can sort the load order.
If that’s possible that would be fantastic @stevebaer !
Are there any potential workarounds you can think of in the meantime?
Not really. If there was a workaround I wouldn’t even consider adjusting the code 
edit: you could structure your gha to reference a helper library that references the other GHA and only call that helper library after initialization is complete. Not exactly a fun coding project.
Nuts. I’ll give that a go, thanks for all the help everyone
Let me know if you come up with a workaround. I would rather not work on this issue if I don’t have to as there are plenty of other higher priority things to take care of.
I’ll take a crack at it, and if I work out a valid workaround I’ll post a sample project here.
Hi Callum,
See if this helps understand what worked for the Geometry Gym plugins.
When grasshopper is loading assemblies for components, it won’t necessarily load all dependencies at that time.
Our solution has two projects (ie 2 dlls). One that is only essential code to define components (ie inputs, outputs, icons etc) and a second dll that has the references to the third party components.
The first dll is renamed to .gha, and in the components solve method we call methods on a static class in the second project.
So the only references to the third party components are in the second project with the static class.
Because grasshopper has loaded the third party dll at startup, and ours only at the time any solving is called, it doesn’t matter if we built against a slightly different version etc.
We simply reference a copy of the 3rd party gha file with the extension renamed to .dll (so if a new version of the 3rd party components is released, we do have to manually repeat that step).
Hope this helps, let me know if it’s not clear.
Cheers,
Jon
I’ll give this a go, thanks Jon!
I have an error when grasshopper load Visualarq. If I start Varq when Rhino is loaded, the problem disappear. I think so that the loading order of Grasshopper is important.
The error is this:
Object: remesher (level 1)
{
Se produjo una excepción en el destino de la invocación.
TargetInvocationException
}
Object: remesher (level 2)
{
Se produjo una excepción de tipo ‘Rhino.Runtime.NotLicensedException’.
NotLicensedException
}
Object: RemeshByColour (level 1)
{
Se produjo una excepción en el destino de la invocación.
TargetInvocationException
}
Object: RemeshByColour (level 2)
{
Se produjo una excepción de tipo ‘Rhino.Runtime.NotLicensedException’.
NotLicensedException
}
It’s pretty much random, there’s so many aspects that may influence it that it’ll be hard to predict.
Does plugin B simply reference plugin A, or must A have been fully loaded first?
I also had problems with the order that Grasshopper uses to load the plugins.
What I was wondering is why grasshopper doesn’t load all gha assemblies into memory first and then create an instance. (new GH_Component).
This way, the constructor is not activated until all plugins have been loaded.
At this moment grasshopper loads a plugin and then directly create an Instance. For example: Activator.CreateInstance ()
of the types with GH_Component as subclass.
Please let me know if the story is clear.
Wouldn’t this only solve the problem of one plugin referencing another?
You should be able to just load the assembly you need on demand, and then when grasshopper loads that assembly as a plugin it’ll just directly use the already loaded data.
I was hoping to multithread the loading of plugins in grasshopper 2.0 by the way, so this problem will become even more acute. However as @stevebaer mentioned, it is possible to inspect references and adjust loading order based on that, which sounds like a good way forward.