[Serialization] Fix diverging rules for editor and runtime serialization of fields and properties

[Eideren]

PR Details

Prevent serializing get-only properties without backing field.

The idea here is that they aren't safe enough to serialize by default since they are functions, getting the value may throw, and since they do not provide a setter to create a value if the getter ever throws, we decided to only include them if the user decorates them with a [DataMember]

Diverging rules between runtime and editor serialization

Yaml can now serialize internal fields if decorated with DataMember, reflecting how serialization and filtering works for properties.
Binary includes properties with internal getters, as long as they are decorated with DataMember as well.

Those two changes were required to ensure that both serializer behaved in the same way.

Related Issue

Didn't find any ?

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My change requires a change to the documentation.
• I have added tests to cover my changes.
• All new and existing tests passed.

Pinging @IXLLEGACYIXL and @manio143 to take a look into this.

[manio143]

Note that anything in Stride.Core.Assets and Design wasn't running with binary serialization.

[Eideren]

This test has been removed as omitting object type when they match the type at initialization but diverge from the member's return type has been deprecated in a previous pr.
You'll see more changes related to this in other tests.

[manio143]

I'm surprised there's so many places which use private setters and are serializable, nice work! - Being explicit about it seems better.

[Eideren]

There's a fair amount members in the engine that don't conform with the binary's rules, i.e.: a bunch of

[DataMember]
public float MyVal { get; private set; }

But if they did end up at runtime they would have been broken before this change anyway since binary never supported private or protected members. I've looked at a couple and they seem to be used for either the UpdateEngine or for editor-only serialization.

[IXLLEGACYIXL]

There's a fair amount members in the engine that don't conform with the binary's rules, i.e.: a bunch of

[DataMember]
public float MyVal { get; private set; }

But if they did end up at runtime they would have been broken before this change anyway since binary never supported private or protected members. I've looked at a couple and they seem to be used for either the UpdateEngine or for editor-only serialization.

this is an invalid case and is not allowed.. atleast it should be and my diagnostics count that as error

but i only found around 8 cases with invalid combinations

[Eideren]

Yes, as I said, those are only in our source and used only in the editor, right now yaml still allows them through to avoid breaking everything until we take care of them. If you have an easy way to detect them feel free to share, what I was using for internal doesn't scale to private/protected.

[IXLLEGACYIXL]

Yes, as I said, those are only in our source and used only in the editor, right now yaml still allows them through to avoid breaking everything until we take care of them. If you have an easy way to detect them feel free to share, what I was using for internal doesn't scale to private/protected.

https://gist.github.com/IXLLEGACYIXL/b311896965b67af082eafde723619b54
i cant find more , mybe they dont ref stride core in their packages?

[Eideren]

We've discussed a bit more on discord and ended up agreeing on a less restrictive rule, there's a document covering it over here.
My comment there #1875 (comment) wasn't very explicit in what I meant, in that, at the time I wanted to prevent any and all usage of { get; private/protected set; } from being serialized while @IXLLEGACYIXL / Joreyk thought this was specifically about value types not being assignable when using a private/protected setter.

Last PR fixed the issue Joreyk logged.

[Eideren]

Will merge this one once #1694 is merged to avoid more merge conflicts over there.
Might introduce conflicts on this one but we'll see.

[IXLLEGACYIXL]

i have one last thing.
in object descriptor is this code

            // Member is not displayed if there is a YamlIgnore attribute on it
            if (AttributeRegistry.GetAttribute<DataMemberIgnoreAttribute>(memberInfo) != null)
                return false;

the comment is wrong, probably its a leftover from yamldotnet migration like manio said in discord
could you maybe remove it/alter it?