Why do I have to load a dll with a RhinoPython script before I can use in in a GHPython script?

I have a script in a GHPython component that loads a library like so:

sys.path.append(r"[MY USER PATH]\AppData\Roaming\McNeel\Rhinoceros\6.0\scripts\libraries\accord_3-8-0\net462")
import Accord.Statistics as ast

If I load Rhino and run this script it will give a TypeLoadException Error (as if the library can’t be found) like so:

But if I run a script from the Rhino Python editor with the exact same three-line import prior to running the GHPython script, everything’s fine. What’s going on here? Is it a path thing?

Hoping this is a known problem so example files not necessary (might be a pain to provide all the relevant accord library files), but if more information is needed I’ll put together an example file.

Generally, sys.path is not the clr.AddReference locations source. You should use AddReferenceToFileAndPath(). AddRefence uses the .Net locations scavenging system, and that does not know about sys.path. McNeel adds some fixed number of locations for the assembly resolver, and those are the ones in the EditPythonScriptEditor Options panel.

I think something else is going on. For example, there could be a Grasshopper add-on that is loading the wrong type of assembly and therefore ICovariantTransform2 is not found. Notice how it is complaining about that particular type, not about the entire assembly.

This might still not be the entire set of issues here. Sorry, it looks like it will be difficult to entirely remote-debug this, so I want to try all possibilities.

The Assembly Resolver for IronPython was not written by me. I’ll cc @stevebaer and @Alain as they might know more.

I have no problem loading the assembly in Grasshopper using AddReferenceToFilePath without first running a RhinoPython script

1 Like

Solved – I had copies of some (but not all) Accord dlls floating in the Grasshopper Libraries folder. Once they were cleaned up, no problems using AddReferenceToFileAndPath. Thanks.

1 Like