System.Text.Json throws InvalidOperationExcetpion.

System.InvalidOperationException: Each parameter in constructor 'Void .ctor(System.Object)' on type 'ConsoleApp36.MyClass' must bind to an object member on deserialization. Each parameter name must be the camel case equivalent of an object member named with the pascal case naming convention.

Newtonsoft.Json throws InvalidCastException(because object is deserialized to long)

Unable to cast object of type 'System.Int64' to type 'System.Int32'.

Exception is good.
But if you think about things like, for example, how do you think about upcast (which is OK, right?) I also think that boxing is a more consistent behavior.

Upcasting is OK, although that would be weird that the constructor would have to downcast its argument to match the member type.
@neuecc, when you say boxing is more consistent, I wonder what it's consistent with? You already identified that System.Text.Json and Newtonsoft.Json throw instead of boxing.

@AArnott

The serializer doesn't get involved with the body of the constructor.

binary -> deserialize field(int) -> constructor(object)

It causes only upcast, int -> object.

It's more like JSON.NET.
JSON.NET passes a deserialized value (long) to the constructor(object).
Fail reason, long -> int cast is the body of ctor.
(If it is a long field, the deserialization succeeds).

MessagePack has a higher chance of successful deserialization than JSON.NET because it is more strictly type-preserving than JSON, so int is int.

Ok, so it sounds like you're in favor of this change. Very well. :)

@ProductiveRage Can you add a test for a ctor parameter type of int when the member type is long? I wonder if we still have CLR exceptions thrown when the value types don't match.

@AArnott Sorry it's taken me a few days. I expected that it would work with the scenario that you proposed because I presumed that int would be assignable-from long but that is not the case and the following class:

[MessagePackObject]
public class SourceWithLongMemberAndIntCtorArg
{
    public SourceWithLongMemberAndIntCtorArg(int value) => Value = value;

    [Key(0)]
    public long Value { get; }
}

.. will fail at the line var serialised = MessagePackSerializer.Serialize(source); in the code below -

var source = new SourceWithLongMemberAndIntCtorArg(10);
var serialised = MessagePackSerializer.Serialize(source);
var clone = MessagePackSerializer.Deserialize<SourceWithLongMemberAndIntCtorArg>(serialised);
Console.WriteLine(clone.Value);

The error (as expected) is:

MessagePackDynamicObjectResolverException: can't find matched constructor. type:Tester.SourceWithLongMemberAndIntCtorArg

The same error occurs if the constructor argument is a long and the member and int because long is not assignable from int, nor is int assignable from long (they may be cast from one to another but IsAssignableFrom returns false for both directions).

Do you think that it makes sense to add any more code for scenarios similar to this in order for my original change to make sense?

Thanks for testing. That exception is good. I don't mind unequal value types failing, but I was hoping it was not a CLR engine exception and your report is that it is not. So that's good. :)