algorithmic modeling for Rhino
I previously developed a plugin that uses a custom datatype (which implements IGH_GeometricGoo). Now I am developing a new plugin and I want to use the same custom datatype in this one as well, So I added the same classes to this plugin as well.
But when I try to get the data from my old plugin component, I see an error saying the data cannot be cast from one type to another. They are the same datatype but in different assemblies, that is all.
I searched in stackoverflow about this and saw suggestions of serializing the object to a json string and then deserializing it again. But deserializing a json requires an empty constructor so grasshopper then throws an error saying it cannot create an instance of IGH_GeometricGoo (because my custom dataype implements some geometry as fields within the class)
I can post the code if needed.
How can I solve this ?
Thanks in advance !
They are the same datatype but in different assemblies, that is all.
That's not the way .NET sees it. They are different types, defined in different assemblies, with different type-ids. Just because they happen to act in an identical way doesn't mean they are interchangeable.
Your options are:
Just to add to David's already-thorough answer:
For option 2 I often rely on Newtonsoft's Json library - it has some useful mechanisms for serializing / deserializing dot net objects - JsonConvert.SerializeObject and JsonConvert.DeserializeObject.
I tried that before, but Json Deserializer requires a constructor with 0 arguments. So It cannot deserialize IGH_GeometricGoo. I ended up using a dictionary instead. Thank you !
After trying everything else, I ended up using Dictionary. Thanks !
The third option is the technically correct one (which is the best kind of correct).
I usually structure my gh-related code into 3 parts:
- core ("agnostic" part of the code)
- common (Goos and Parameters)
- plugin (gha, exposes the core using the common)
This way you can have many plugins (also developed by other people) pointing to the same common and core libraries, and also passing the same types between each other.
One catch in this approach: Grasshopper won't expose the Parameters from the dll... The hack around this problem is to declare classes in the plugin which do nothing but inherit from Parameters of the common library.
As David says, distribution and versioning are a bit tricky, but hey let the developers do their job.