Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

camelCase serialisation in output binding. #209

Closed
Euan-McVie opened this issue Apr 23, 2021 · 5 comments · Fixed by #248
Closed

camelCase serialisation in output binding. #209

Euan-McVie opened this issue Apr 23, 2021 · 5 comments · Fixed by #248

Comments

@Euan-McVie
Copy link

https://docs.microsoft.com/en-us/aspnet/core/signalr/configuration?view=aspnetcore-5.0&tabs=dotnet#jsonmessagepack-serialization-options

If self hosting then it defaults to using camelCase, but it appears that the azure function version requires us to manually serialise the message ourselves.

Can either the default behaviour be changed to match the normal client/server defaults or some form of configuration added to enable specifying the behaviour?

@Y-Sindo
Copy link
Member

Y-Sindo commented May 10, 2021

Thank you for your advice. We will consider adding json serialization configuration later.

@Y-Sindo
Copy link
Member

Y-Sindo commented May 21, 2021

If you switch to Persistent transport type by adding configuration in the local.settings.json

{
  "Values": {
    "AzureSignalRServiceTransportType": "Persistent",
  },
}

or on the Azure portal, then the Json Serialization library is switched to System.Text.Json and the behaviour would be the same as self-host SignalR. Could you try it?

FYI:

@M0ns1gn0r
Copy link

"AzureSignalRServiceTransportType": "Persistent", doesn't work in my case, it leads to errors during server push (maybe because I am using the SignalR emulator). And frankly, this looks more like a hack than a solution.

Is there another way to pass the serialization settings to be used by SignalR?

@Euan-McVie
Copy link
Author

Euan-McVie commented Jun 11, 2021

I accidentally found the following actually seems to fix it (I was fixing my Cosmos trigger which has a similar issue that was fixed by changing JsonConvert and setting the UseDefaultJsonSerialization = true flag)
I guess the Json.Net uses JsonConvert defaults as well, but just doesn't require the extra flag.

[assembly: FunctionsStartup(typeof(Startup))]

namespace E2ECosmos.Functions
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            JsonConvert.DefaultSettings = () =>
            {
                var settings = new JsonSerializerSettings();
                SetSerializerSettings(settings);
                return settings;
            };

            builder.Services.AddMvcCore()
                .AddNewtonsoftJson(options => SetSerializerSettings(options.SerializerSettings));
        }

        private static void SetSerializerSettings(JsonSerializerSettings settings)
        {
            settings.ContractResolver = new CamelCasePropertyNamesContractResolver();
            settings = settings.ConfigureForNodaTime(DateTimeZoneProviders.Tzdb);
            settings.Converters.Add(new StringEnumConverter());
        }
    }
}

As a side note it is really annoying that the Azure functions team seem unable to keep in sync with the rest of the .net ecosystem.
Makes me want to start looking at AWS again 😉

@Y-Sindo
Copy link
Member

Y-Sindo commented Jun 14, 2021

Sorry for the delayed response and the trouble brought to you. This is a rather big feature, and we are still working on it. Will let you know as soon as we have updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants