This regressed #1308. I'm looking for a mutually acceptable solution.

This change unfortunately broke deserializing for many of our objects. Is there any way to restore the ability to set the values of readonly fields without having to create custom constructors for each object? For example, this is what an object might look like:

[Key(0)] public readonly string Code = "";

[SerializationConstructor]
private MyObject() {}

Before MessagePack 2.3.75 this worked, but after 2.3.75 the Code field is always empty after deserializing. What is the best way to get this working again? Thanks!

IMHO; this shouldn't work. I expect serializer libraries to maintain the "readonly" constraints set by the compiler. The fact that message-pack was writing to readonly fields came as a big surprise to me.

Also, @RobotGizmo, how on earth is that MyObject usable? If the field is readonly, it will always only have the value ""?

I think our issue is that we view the serializer as something that dumps the data from an object then puts it back in blindly. If there is a field with data it should be filled in again unless it's marked with [IgnoreMember]. Otherwise the only solution I can see is to create private SerializationConstructor constructors that take all the fields as parameters. This is much harder to maintain as you have to make sure to keep it in sync with the fields in the class. It would be fantastic to have a resolver (or however we can solve this) like StandardResolverAllowPrivateIncludingReadonly or have a "WriteReadonlyFields" property as an option.

The example above was just a part of the code as a sample, we do have a public constructor as well, like this:

[Key(0)] public readonly string Code = "";

[SerializationConstructor]
private MyObject() {}

public MyObject(string code)
{
    this.Code = code;
}

@RobotGizmo #1314 already corrected the regression. Can you confirm?

@AArnott Thanks, it looks like it's working as it did before with v2.3.85. :)