Bug: Reading in `speckle_type` from Server about speckle-sharp HOT 5 CLOSED

I see, sadly this is not how our SDKs were designed. Speckle assumes that if you want to send an object across 2 different programming languages, you need the object representation on both sides.

Additionally, speckle_type value is computed on our SDK objects based on the actual type it is and it's inheritance. It is not something you can override, the speckle_type of a given object will always tell you what type it is "at that given moment"
This is because speckle_type is used as the JSON discriminator when deserialising, so you can't just set it to anything (well, you can, but it'll revert to Base upon deserialisation if the type you specified was not found)

If you don't want to type out the definitions in C#, just send objects with speckle_type Base from your application and use another property of your choosing to discriminate against (customType?)

As long as your application follows your own rules you should be good to go. That being said... you will be better off just typing them in both languages on the long run.

from speckle-sharp.

Okay, so I found a solution as a work around. If I add new Objects.Geometry.Line(); before I fetch from the server then the objects are serialized to their proper type and speckle_type looks correct. The only problem I see, what happens if I use a custom type but haven't registered the a deserialization type on the receive and instead just need a quick query or something. speckle_type field would still be incorrect?

from speckle-sharp.

Hey @sanchez!

We're aware of this behaviour, and it's something we have no control over.

The way the dotnet runtime works (as far as we've gathered), is that it won't load up DLLs until the moment they're used in some part of the code. This prevent's your computer from loading up a bunch of logic that may or may not be executed.

The problem you're experiencing is due to this dotnet feature, combined with the fact that our deserialiser uses Reflection to cast things to its correct types, but will cast to a more generic type if the specific type does not exist (cases where you don't care about objects specifically, or you don't have access to the type but still want to access it's data)

This means that, when deserialising an object, the deserialiser can only know about the types that are already loaded. This also explains why, if you use a single class within the Objects dll before deserialising, you'll suddenly get all the Objects types deserialised correctly.

In all of our C# connectors, this is guaranteed to be loaded before any deserialisation operation happen by using our KitManager, who will fetch all kits and force-load them into the program. This is the recommended approach if you're targeting some sort of Desktop application and is expected to run alongside the installed speckle connectors.

For any other type of application (web apps, server backends) who do not need to co-exist with our speckle connectors, you are free to solve this issue as you see fit. A more elegant way to "load the Objects kit" without KitManager can be found in our Automate.SDK example repo:

_ = typeof(ObjectsKit).Assembly; // Force objects kit to initialise

https://github.com/specklesystems/SpeckleAutomateDotnetExample/blob/47b0a1ab5e04c43d14b02141d5d433618ac9748f/SpeckleAutomateDotnetExample/AutomateFunction.cs#L15

As for your question regarding Custom Types, the deserialiser will be able to cast to those types as long as the dll holding said types has been loaded up.

You can ensure that with the above trick too ;)

Hope this helps!

from speckle-sharp.

Thanks for the detailed response @AlanRynne. I guess some situations I am thinking of, is say we have some tool produced in JavaScript which pushes some custom objects, but then we want to do some basic querying in CSharp for some reason.

On the CSharp side we don't want to have to type out all the definitions, we might only want to do something simple like get a specific property from an object if the Speckle type starts with a specific namespace. Super simplified but the idea is sort of there I believe.

I would say that even if the object is deserialized to Base, the speckle_type property should still be the original value that's fetched from the server

from speckle-sharp.

No worries, thanks for the info. Since I guess this is by design and not necessarily a bug, I am happy to close this out.

from speckle-sharp.