Open Barsonax opened 4 years ago
Some notes:
AssignFieldError
will be invoked and user-handled. Usually they'll just check for a hardcoded name, but there may be cases where reflection will be involved and name translation required.CompilerGenerated
attribute on both the properties and fields, which we could potentially use to filter out candidates for any matching.XmlSerializer
and potentially others that might write a human-readable format in the future. I'm currently leaning towards the former though, since it reduces the mental load for implementers of specific serialization formats.SerializeType
, replacing FieldInfo
with a struct that has a field info, but also a "serialized name". I'd not make this specific for auto-properties, or even mention them.FormerlySerializedAs
user attributes without having to rely on implementing a SerializeErrorHandler
there.There appears to be a CompilerGenerated attribute on both the properties and fields, which we could potentially use to filter out candidates for any matching.
Oh also on the property? Thats nice. Can make it quite robust then by just checking if theres a attribute on both sides.
EDIT: updated the example on this.
Not the property itself, but its internal getter and setter methods get one. Still, could be useful enough for some sort of verification.
Summary
Currently we try to avoid using auto properties because when serializing a instance the serializer will use the name of the backing fields which have a ugly name like
<Foo>k__BackingField
.Consider changing the serializers to understand the relationship between the backing fields and the properties to allow them to handle these in a nicer way
Analysis
Simple example of getting the backingfield or the autoproperty. No idea if this is stable enough, needs more research.