So, we've got kind of a weird setup, which I'll explain in a bit. The immediate problem we're getting is when we're trying to use an external assembly in our grasshopper component, it doesn't run, and the node has a red note with the error message "Solution exception:Could not load type 'TSplineDN' from assembly 'TSplines, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'."
Here's the setup - our main Rhino plugin is in TSplines.rhp. It's a mixed-mode dll, native c++ and c++/clr. We're hoping to expose a lot of functionality to .net, and this seemed to be the easiest way. We're also using it to build a bridge to better gui stuff in c#.
So, we have a ResolveEventHandler in our c++/clr code that helps us load our other libraries. When I call a function that uses the TSplines assembly, the ResolveEventHandler fires and we're able to point it to the currently running TSplines.rhp.
The problem is that when I try to call my assembly from within Grasshopper, the c++/clr ResolveEventHandler doesn't fire. I tried adding the filename (including full path) with Grasshopper.Kernel.GH_AssemblyResolver.AddSearchNode instead, but it didn't seem to do anything at all.
My current workaround is to have another assembly call a function in TSplines immediately on load, which happens before Grasshopper initializes, which is working fine - the c++/clr ResolveEventHandler fires and then, after Grasshopper loads, my component can then see the TSplines assembly. I was wondering if there's a cleaner way to get my component loading within Grasshopper without having to force my ResolveEventHandler to run before Grasshopper loads.
Tags: