MessagePack Serialization Fails

[GammaSoul]

Describe the bug
Hi there im having some trouble with your library
Using MessagePack (https://github.com/neuecc/MessagePack-CSharp) fails
The application hangs and then i get the error:
Error Wrong Credentials
Handshake with server failed.
Apart from the having to use the standard MessagePack resolver Serializer because there is some types of object to be serialized, it fails once that is resolved.
I need to serialize some types like NodaTime and others that MessagePack supports. Also MessagePack has the best performance.

Update:
When using the included Bson Serialization and i enclose my types in a data contract object then it works. does not work if the type is a raw method parameter.

So this is really just about supporting MessagePack for performance as i got Bson to work with my Types.
.
Thank you for having a look at this if you can 👍

[theRainbird]

Hi GammaSoul,

MessagePack is difficult to implement, because you have to decorate every type that is serialized with attributes ([MessagePackObject] and [Key]) or provide other metadata. CoreRemoting has some internal classes that describe messages. This classes are serialized using the plugged in serializer. Because this classes are not decorated with MessagePack stuff, serialization fails.

[yallie]

Maybe it's achievable using https://github.com/ModernRonin/MessagePack.Attributeless library.

Will definitely require creating a separate package, say, CoreRemoting.Serialization.MessagePack,
depending on both MessagePack and MessagePack.Attributeless packages along with CoreRemoting.

Attributeless library allows to list serializable types and properties externally, without attributes.
The dependency graph would be something like this:

graph
  CoreRemoting.Serialization.MessagePack --> CoreRemoting
  CoreRemoting.Serialization.MessagePack --> MessagePack
  CoreRemoting.Serialization.MessagePack --> MessagePack.Attributeless
  MessagePack.Attributeless --> MessagePack

Loading

Not sure if it worth the effort though :)

[theRainbird]

Not sure if it worth the effort though :)

Serialization is still an issue. With .NET 9 the old BinaryFormatter will be cut off by default. Only special properties in project file will reactive unsupported usage.
Because if this I'm planning to put move binary serialization in a separate package. To get the CoreRemoting base package clean from dependencies that will cause security warnings.

Attributeless MessagePack moves the attributes outside to an external structure, like the builder in EF Core.
Personally I don't like the concept. Serialization should work "invisible" in best case. Registering serialization rules for every type at a centralized place is the opposite of that.
Unluckily MessagePack and ProtoBuf are no good replacement for BinaryFormatter.

MessagePack may be interessting as separate package for special use cases.

My current approach is to pimp Json.NET BSON/JSON serialization with custom converters (e.g. for DataTables / DataSet).

[yallie]

Serialization is still an issue. With .NET 9 the old BinaryFormatter will be cut off by default.

That's sad...

I've seen a couple of alternative binary serializers that don't require attributes.
Not sure whether they support .NET 9 though:

• Hyperion/Wire — https://github.com/akkadotnet/Hyperion
• SlimSerializer — https://github.com/azist/azos/tree/master/src/Azos/Serialization/Slim

Personally I don't like the concept. Serialization should work "invisible" in best case.
Registering serialization rules for every type at a centralized place is the opposite of that.

I believe attributeless mode can be mixed with normal message pack attributes.

So that CoreRemoting classes are registered using the fluent builder (to avoid the dependency).
But user domain classes are decorated with attributes. Something like that.

My current approach is to pimp Json.NET BSON/JSON serialization with custom converters

The downside of BSON/JSON (afaik) is that they don't handle circular references and duplicates.
Something like new List<MyClass> { a, a, a } will be deserialized as a list of three different a's.
I don't know is there any workaround for this issue.

[theRainbird]

So that CoreRemoting classes are registered using the fluent builder (to avoid the dependency).
But user domain classes are decorated with attributes. Something like that.

MessagePack is not bad, but may be not the best choice as default serializer.

The downside of BSON/JSON (afaik) is that they don't handle circular references and duplicates.
Something like new List { a, a, a } will be deserialized as a list of three different a's.
I don't know is there any workaround for this issue.

JSON.NET is able to preserve references. The behavior can be controlled via PreserveReferencesHandling setting.
See https://www.newtonsoft.com/json/help/html/preserveobjectreferences.htm for details.
Currently CoreRemoting uses the setting PreserveReferencesHandling.Objects, which only preserves references inside object graphs. But this can be changed to PreserveReferencesHandling.All to preserve references also in arrays.

[yallie]

MessagePack is not bad, but may be not the best choice as default serializer.

Of course not the default serializer, I agree.
Question was, whether it's possible to use MessagePack at all, as far as I can see.
Attributeless hack just solves the unwanted dependency issue in the core library.

JSON.NET is able to preserve references. The behavior can be controlled via PreserveReferencesHandling setting.

Great! I was unaware of this.
Even better, looks like this feature is not specific to JSON.NET.
System.Text.Json also supports this reference handling.

[theRainbird]

Even better, looks like this feature is not specific to JSON.NET.
System.Text.Json also supports this

Yes, but other features like TypeNameHandling are currently not supported in System.Test.Json.

You can find a detailed feature comparison here:
https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/migrate-from-newtonsoft?pivots=dotnet-9-0