Closed Euan-McVie closed 3 years ago
Thank you for your advice. We will consider adding json serialization configuration later.
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:
The default JSON serialization options for self-host SignalR: https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/common/Protocols.Json/src/Protocol/JsonHubProtocol.cs#L794-L780
By default service transport type is Transient
and using Newtonsoft.Json
as the JSON library.
"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?
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 😉
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.
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?