Dialog doesn't launch when 3rd party plugins are on GH canvas
I tried using Freighter to package up a daylighting script I set up using HumanUI and Ladybug. Freighter installed correctly without any issues, but when I ran the Rhino command, nothing appeared. The GH Document is getting saved and the console says "Freighter loaded" but a window doesn't appear. Using default components works fine.
Comments (10)
-
repo owner -
repo owner -
assigned issue to
-
assigned issue to
-
reporter After some debugging, it's an issue on creating the form. Details and location of the error here:
#! System.BadImageFormatException was unhandled by user code HResult=-2146234344 Message=Could not load file or assembly 'cairo.dll' or one of its dependencies. The module was expected to contain an assembly manifest. Source=mscorlib FileName=cairo.dll FusionLog="" StackTrace: at System.Reflection.AssemblyName.nGetFileInformation(String s) at System.Reflection.AssemblyName.GetAssemblyName(String assemblyFile) at ProvingGround.Freighter.UI.formFreighter.GetGrasshopper() in C:\Users\dsiroky\Source\Repos\Freighter\ProvingGround.Freighter\UI\formFreighter.xaml.cs:line 229 at ProvingGround.Freighter.UI.formFreighter.DoSetup() in C:\Users\dsiroky\Source\Repos\Freighter\ProvingGround.Freighter\UI\formFreighter.xaml.cs:line 83 at ProvingGround.Freighter.UI.formFreighter..ctor(RhinoDoc doc) in C:\Users\dsiroky\Source\Repos\Freighter\ProvingGround.Freighter\UI\formFreighter.xaml.cs:line 73 at ProvingGround.Freighter.FreighterCmd.RunCommand(RhinoDoc doc, RunMode mode) in C:\Users\dsiroky\Source\Repos\Freighter\ProvingGround.Freighter\FreighterCmd.cs:line 89 at Rhino.Commands.Command.OnRunCommand(Int32 command_serial_number, Int32 doc_id, Int32 mode) InnerException: System.BadImageFormatException HResult=-2146234344 Message=Could not load file or assembly 'cairo.dll' or one of its dependencies. The module was expected to contain an assembly manifest. FileName=cairo.dll FusionLog="" InnerException:
Cairo.dll is used by Heron, one the random 3rd party plugin's nodes I was using. It seems like the issue is related to referencing assemblies that are either x86 or created in a different version of .NET
Also, removing the Leap Motion libraries (leap*.dll) for Firefly from %APPDATA%/Grasshopper/Libraries resolved this issue. A temporary fix is to place the offending .dll files into a subfolder. Unless it's being used in the script, it isn't trying to be read and the form launches fine.
-
tried putting the firefly leap motion dll's into a subfolder but am still experiencing the same issue: any addin in the canvas prevents the freighter dialog box from starting... including lunchbox
-
Issue
#3was marked as a duplicate of this issue. -
Ok i think i've figured it out: firefly was the offending adding. but moving the dll's does not fix it. you need to remove it completely form your computer by uninstalling it.
in the process i've come up with a list of plugins feighter does support:
- lunchbox
- conduit
- metahopper
- human
- human ui
- tt toolbox
- bifocals
- treesloth
- tree8
- mesh+
- elefront
- honeybee+laydybug
- python
- intralattic
- smartform
- kangaroo
- fabtools
- heteroptera
- squid
- advanced surfacing tools
- flux
currently freighter does not support:
- firefly
-
I really have to say to everyone that put time into making freighter work: WELL DONE. sorry for my noisy trouble shooting. but this really is a huge step forward for grasshopper... especially in pair with conduit. i can package up what i've been working on and send it to someone or give it to a team to present (using conduit). or i can archive scripts with all the dependencies.
once again... VERY WELL DONE!
-
Hi Jeremy...thanks so much for the extensive research and feedback on this issue. I will sit down and take a look.
-
Okay, so this should be fixed in the latest build. It seems that some plug-ins list particular dependencies that can't always be loaded...when this was happening, it was throwing an error that caused the main form to fail to load, which is what was happening here. I have taken the opportunity to add a better dependency lookup (it now recurses through each dependency to see if they too have nested dependencies) and which will pass errors when particular dependencies can't be found, and list them in the dialog. In cases where it finds errors, it strongly recommends in the readme that users do a "hard install" of a plug-in, rather than using Freighter's "copy and unblock" approach, although left alone it will still try.
Thanks again for the detailed feedback! It helped a great deal here.
-
- changed status to resolved
- Log in to comment
cc: @davestasiuk