Serializing a property without a setter throws "No set accessor" when the class has a constructor

[F2]

Serializing a property without a setter throws "No set accessor" when the class has a constructor

[AArnott]

When using non-default constructors for deserialization, you should apply [SerializationConstructor] on the constructor. Does that resolve the issue?

[F2]

Thanks for the suggestion. Unfortunately no, applying [SerializationConstructor] to the constructor does not change anything - I still get the "No set accessor" exception.

However, if I add an extra constructor that is never used by me or the serialization process, then it works:

[SerializationConstructor]
private Player()
{
    // This will never be called
    throw new NotImplementedException();
}

Still, it does not make much sense to me why such a constructor is needed - and indeed, it was not necessary in previous versions of the nuget.

It makes sense in the case of deserialization when it needs a constructor to construct the object, but not serialization.

[AArnott]

Thanks for trying it out. I agree this seems like a regression and I'll try to find time to investigate and correct it.

I agree deserialization's requirements aren't fundamentally the same as for serialization. But the dynamic object resolver creates a formatter to serialize and deserialize at the same time, and at the moment, it enforces requirements for both scenarios when the formatter is generated. That is something we could improve on in the future.

[AArnott]

I can repro the failure. But now that I'm looking at it more closely, I agree with it, modulo the missing support for non-deserializable objects that I mentioned before. For future reference, here's why:

• The only property that could be effectively serialized is your Name property.
• Scores is ignored by an explicit attribute.
• TotalScore is supposed to be serialized, but it doesn't store a value. It's computed from the ignored property. And it has no setter as a result. So the serialized form cannot be used to construct a deserialized object.

This is as @F2 said in the first place. I just misunderstood the nuance.
Anyway, if and when MessagePack's DynamicObjectResolver ever supports types that can only be serialized or deserialized (not both), then this is a good example of a type that should start working at that point. I imagine the way we could achieve that is for the resolver to record that an object can only go one direction, and emit a formatter that throws when going the other direction. Ideally, the exception thrown if used in the unsupported direction would match the exception that the resolver itself currently throws so that it can point the user in the right direction to fix the problem if they intended bidirectional serialization.

I suspect the fact that this "worked" in prior versions was probably due to a hole in detection of the unsupported scenario, and you got lucky. To upgrade MessagePack and keep working, you can either use the workarounds you already mentioned, or write a custom formatter for this type.

I'm going to close this issue as Won't Fix because we don't have plans to support uni-directional serialization in the DynamicObjectResolver any time soon.