Shared custom classes between Rhino plugin and Grasshopper plugin

I’ve developed a C# Rhino plugin, and I’m now working on a C# Grasshopper plugin to go along with it. One problem I’m running into is how to access classes in my Rhino plugin from my GH plugin. For example, I want to create (essentially: bake to the Rhino doc) a CustomCurveObject that is defined in my Rhino plugin, from a component in my Grasshopper plugin.

I have this working for the most part–with one caveat. The GH plugin references “RhinoPlugin.dll” in visual studio, but it is actually “RhinoPlugin**.rhp**” that is installed in Rhino. This leads to some null references that I don’t fully understand (possibly some assembly/namespace confusion). However, what I’ve discovered is that, if I go to my PluginManager and install “RhinoProject.dll” (instead of the .rhp), these issues are resolved.

This does not seem like a real solution though, as I ultimately need to deliver the .rhp to users. But Visual Studio will not let me reference the .rhp from the Grasshopper project–only the .dll. Is there a way to structure my projects to solve this problem?

I’ve considered moving my CustomCurveObject (and other classes/logic that get used in both the Rhino and GH plugins) to a separate project that would be referenced by both the Rhino and GH projects. But I’m not terribly excited about having an extra dll. Curious if anyone has any suggestions.

This will be what we’ll suggest. Any data types you want shared between different plug-ins you should drop into a separate assembly and reference them from both.

This is how I do it for RhinoCycles integration where there are actually several DLLs containing the data types and core functionality that get referenced by RhinoCycles and GhShaderNodes.

p.s. the title of this topic doesn’t really seem to fit the text in the OP?

1 Like

@nathanletwory Thank you for the feedback. I’ll move forward with that solution. Also, I updated the title to better reflect the post.

@nathanletwory I’m still running into trouble here. Have you found a way to define UserData types in your supporting dlls? From what I’m finding this may not be possible. I’m getting the same NullReference discussed here: https://discourse.mcneel.com/t/add-userdata-object-reference-not-set-to-the-instance-of-an-object/64877

Might need to go back to referencing the rhino project from the gh project, although I’m sure this will present its own problems. Just seems like there must be a way to instantiate custom user data from GH??

One idea I have:

  • Move CustomCurveObject and CustomUserData back to the RhinoProject so it works again

  • Reference RhinoProject.dll in GHProject

  • Create a CustomCurveObject from within a custom GH component without instantiating it’s CustomUserData (creating custom objects–not userdata–seems to work fine here)

  • Use RunScript to kick off a command from the RhinoProject that searches for CustomCurveObjects without the proper CustomUserData, and finishes their construction

I’m not 100% sure I will be able to pass the requisite data around, but we’ll find out.

I wasn’t aware you had custom user data as well.

I don’t know of a good approach to handle that. There hasn’t been work on providing better data access for custom user data since @stevebaer mentioned that in the thread.

@nathanletwory @stevebaer Understood. For what it’s worth, add me to the list of people who think this would be valuable.

I’ll post back here if I find a valid workaround.

The workaround suggested above works. Basically I just store the data necessary to build the CustomUserData on the CustomCurveObject when I create it from GH, and then have a Rhino command come back and use that data to actually build the CustomUserData.

Feels hacky though.

Hi @ScottMitchell,

Here is something I typed up a while back - perhaps it will give you a few ideas.

– Dale

1 Like