Consider changing or adding to the MessagePackProtocol options

[BrennanConroy]

In MessagePack-CSharp v2 there is a MessagePackSerializerOptions class that can be passed to the serializer. Currently we expose a list of IFormatterResolvers for the user to configure, but there are other options like compression and IMessagePackFormatter that we don't expose.

Options: https://github.com/neuecc/MessagePack-CSharp/blob/8eeb7b8ab71ff7d70f8b2013589423eadbba90b7/src/MessagePack.UnityClient/Assets/Scripts/MessagePack/MessagePackSerializerOptions.cs#L15

Discussion: #18133 (comment)

[tebeco]

hello @BrennanConroy
Sorry to beother you about it again, i remember you wrote a comment ... somewhere ... containing the ApiReview + link to the UnitTest validation custom MessagePack Options/Formater/Resolvers

i can't seem to find your comment here or in my mail or on aspnet/aspnetcore ...
As I'm still not sure if i have the background to submit an idea of these new "options", i supposed that having the equivalent of this "lost message" would be nice here

I suppose it was pointing on this :

aspnetcore/src/SignalR/server/SignalR/test/HubConnectionHandlerTests.cs

Lines 2363 to 2400 in 7def102

	[Fact]
	public async Task HubOptionsCanUseCustomMessagePackSettings()
	{
	using (StartVerifiableLog())
	{
	var serviceProvider = HubConnectionHandlerTestUtils.CreateServiceProvider(services =>
	{
	services.AddSignalR()
	.AddMessagePackProtocol(options =>
	{
	options.FormatterResolvers.Insert(0, new CustomFormatter());
	});
	}, LoggerFactory);
	var connectionHandler = serviceProvider.GetService<HubConnectionHandler<MethodHub>>();
	var msgPackOptions = serviceProvider.GetRequiredService<IOptions<MessagePackHubProtocolOptions>>();
	using (var client = new TestClient(protocol: new MessagePackHubProtocol(msgPackOptions)))
	{
	client.SupportedFormats = TransferFormat.Binary;
	var connectionHandlerTask = await client.ConnectAsync(connectionHandler);
	await client.Connected.OrTimeout();
	await client.SendInvocationAsync(nameof(MethodHub.BroadcastItem)).OrTimeout();
	var message = Assert.IsType<InvocationMessage>(await client.ReadAsync().OrTimeout());
	var result = message.Arguments[0] as Dictionary<object, object>;
	Assert.Equal("formattedString", result["Message"]);
	Assert.Equal("formattedString", result["paramName"]);
	client.Dispose();
	await connectionHandlerTask.OrTimeout();
	}
	}
	}

[tebeco]

So after trying to understand what could be the various ideas, i'm not sure what/how to change ^^

If i describe what i understand from the "code flow" :

• The current MessagePackHubProtocolOptions class from SignalR that "kinda wrap" the message pack one expose an IList<IFormatterResolver>
• MessagePackOptions exposes only a SINGLE IFormatResovler

This transition from "Multiple" to a "Single" is done in a call to SetupResolver from the MessagePackHubProtocol constructor,

• It checks if the consumer changed the default one (either by count or ref check)
• then uses static method from MessagePack : MessagePackSerializerOptions.Standard.WithResolver(resolver)

The Cache<T> is kinda like "smart Dictionary<Type, Resolver> leveraging on the fact that static ctor being threadsafe i guess ?

Questions :

• Why does SignalR exposes an IList<>, since at the end it results in a single FormatterResolver ?
  I suppose that if it's designed like this there's a good reason for that, i'm curious here ^^

• It "could" directly resolves an IOptions<MessagePackSerializerOptions>
  It would look like the same idea behind JsonOption for Mvc => 1 Formater, and you just need to properly .Configure it as a consumer ?

There's probably other things / way i did not though about ^^

[tebeco]

would love @AArnott point of view here, as you probably have a way better insight than me here

[AArnott]

Exposing MessagePackSerializerOptions will give the app owner more control. They could turn on compression, fiddle with security settings, etc.

Does aspnetcore require any resolvers to be included in the list, for its own types? If not, then exposing MessagePackSerializerOptions to the user and using their exact instance internally makes sense, IMO.
But if aspnetcore needs to ensure that some of its own types can be serialized via some particular resolver, it gets more complicated. You can check out our MessagePackFormatter class from StreamJsonRpc as an example where we let the user supply their own MessagePackSerializerOptions instance (see the SetMessagePackSerializerOptions method), but we then alter it slightly in order to 'wrap' the user-supplied resolvers with our own. We take very special care to only use the user's selected resolvers for user data, and only our own resolvers for our types that tend to 'wrap' that user data.

[tebeco]

I forgot to mention that by default the resolvers are :

            public static readonly IList<IFormatterResolver> Resolvers = new IFormatterResolver[]
            {
                DynamicEnumAsStringResolver.Instance,
                ContractlessStandardResolver.Instance,
            };