Format compatibility with original messagePack library.

[troepolik]

@AArnott can you help with the question?
should I think the format of body producing by this library is the same with original MessagePack library? for contractless mode (key is a property name).
If not, should I use separate deserializer on java script side to deserialize message created by this library or I can use the same?

I tried to check format compatibility serializing message by NerdBank and deserializing by original (I use C# library)
and for some cases it works , but for some it throws error.
But I'am not sure mb I have to use some settings to make format compatible...
my simple example:

Nerdbank.MessagePack.MessagePackSerializer nerd = new ();
var nerdBody = nerd.Serialize(in msg);

//deserialize with original
MessagePackSerializerOptions serializeOptions = MessagePack.Resolvers.ContractlessStandardResolver
        .Options;
var msg2 = MessagePackSerializer.Deserialize<T>(nerdBody , serializeOptions );

[AArnott]

I think your questions are answered in this doc. Can you review it and reply with any remaining questions?

[troepolik]

@AArnott thank you, excellent doc.
But I still in doubt)
"Nerdbank.MessagePack can read MessagePack-CSharp serialized objects, but MessagePack-CSharp cannot read some of the objects serialized by Nerdbank.MessagePack."

Do you mean here the special index map mode for many "holes" (not my case because we use property name as key)? or it related to differences for some primitives without a specified encoding ?

"cannot read some of the objects serialized by Nerdbank.MessagePack." is it related to java script library as well?

[AArnott]

Yes, the special index map for many "holes" is unique to Nerdbank.MessagePack. Any other msgpack parser can read it, but may not be able to effectively deserialize it into a convenient object graph without work to match the feature in this library.
Javascript msgpack packages don't tend to deserialize msgpack, but only to decode it.

But as you say, if you just use property names, there won't be any issue. All messagepack libraries ought to be able to decode/deserialize it just fine.

Then yes, there are certain primitives that the msgpack spec doesn't describe an encoding for, and nerdbank.messagepack defines extension encodings for and other libraries may or may not interop with. This is for things like UInt128, BigInteger and Guid.