Open jkerken opened 1 week ago
What you're trying to do generally makes sense (using the generated SDK so it's in sync with the schema), but the output classes weren't intended to be serialized in this way -- they're really just meant to be targets of deserialization. Typically, there would be an associated input class that can be serialized correctly.
Note: We're currently looking into making it easier to create "MLC"s, but with little-to-no provider boilerplate and automatic schema creation from your component definition in C#. So rather than using the generated SDK in your component provider implementation, we'd drive schema generation from your code.
So we may have an edge usecase that show some intressing beauvoirs for the serialiazation. For Context: We have a MLC c# provider that uses the sdk generator classes as the actual output objects in the components provider implementations, to be sure our output and the schema stay in sync. We also use c# for the consuming side with the exact same sdk.
Now the actual issues are the generator output classes, they look like this:
The problem is now they get serialized like:
But then the deserialization takes the names of the properties from the Output Contructors arguments names
So the expected value is now
Since this does not match up. The client side sets all fields to null and then the programm crashes since they were not optional.
There are now two worarounds: Adding [Output( Name = "name"] to the property or [OutputConstructorParameter("Name")] on the constructor.
Bot both would require you to modify the generated.
I am happy to work on a fix, but I am really unsure how/where this is actually to be fixed. So wanted to gather some feedback on this bug.