Dialog doesn't launch when 3rd party plugins are on GH canvas

[Dan Siroky]

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.

[Nathan Miller]

cc: @davestasiuk

[Dan Siroky]

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.

[Jeremy Luebker]

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

[Jeremy Luebker]

Issue #3 was marked as a duplicate of this issue.

[Jeremy Luebker]

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

[Jeremy Luebker]

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!

[David Stasiuk]

Hi Jeremy...thanks so much for the extensive research and feedback on this issue. I will sit down and take a look.

[David Stasiuk]

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.