Grasshopper

algorithmic modeling for Rhino

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.

Views: 1064

Replies to This Discussion

Hi Tom,

there's nothing printed in the Rhino Command History about "Assembly Resolves being required"?

--
David Rutten
david@mcneel.com
Seattle, WA
I'm assuming all your assemblies are not in the same folder as the standard Grasshopper components?

This may not be related, but since version 0.8.0001 (I think) my assembly resolving code in the grasshopper priority loading class seemed to stop working. My required classes were loaded by Rhino at startup, so I temporarily got users to untick COFF loading in the rhino command GrasshopperDeveloperSettings.

Subsequent to discussions with David, I've now moved my gha files into my plugin folder, and the rhino plugin initialization code has a check in it that the plugin folder is included in the Grasshopper assembly loading path.

Hope you can find a solution.

Cheers,,

Jon
I'm about to remove all Assembly Resolvers from Grasshopper since I think having one in RhinoCommon is more than enough. We just need to hook up some basic stuff there so you can actually add additional search paths. Hopefully the next release of Grasshopper+RhinoCommon will load assemblies correctly.

--
David Rutten
david@mcneel.com
Seattle, WA

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service