Using same custom datatype in two plugins

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 !

Replies to This Discussion

Permalink Reply by David Rutten on May 23, 2017 at 2:16am

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:

Only define the type once in the assembly which instantiates this type, then use Reflection or dynamic to access its fields from another assembly. This solution won't work if both assemblies need to instantiate the type.
Define the type in both assemblies, but make sure that there's a way to 'reconvert' it to 'itself'. For example you could override the ToString() method to deserialize the type, and add a constructor which takes a string and serializes it. This means a lot of duplication which could be a problem if your type contains lots of data or if your type contain unserializable data such as socket connections.
Create a third assembly which defines the type, and reference that assembly in both your projects (this is the official solution usually given, but obviously complicates distribution and versioning).
Switch to a platform data type that both assemblies already have access to, such as Dictionary or List<T> or something.

Permalink Reply by Andrew Heumann on May 24, 2017 at 12:07pm

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.

Permalink Reply by Ranjeeth Mahankali on June 7, 2017 at 12:43pm

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 !

Permalink Reply by Ranjeeth Mahankali on June 7, 2017 at 12:42pm

After trying everything else, I ended up using Dictionary. Thanks !

Permalink Reply by Mateusz Zwierzycki on June 7, 2017 at 3:29pm

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.

RSS