The Problem
Today I went into a problem trying to configure SignalR to automatically serialize my data contracts in camel cases. Having done that once for Web API, I knew that it can be done easily by changing the contract resolver of JSON.NET to CamelCasePropertyNamesContractResolver. So I went ahead and incorporate the new ContractResolver to SignalR:
|
1 2 3 |
var serializerSettings = new JsonSerializerSettings { ContractResolver = new CamelCasePropertyNamesContractResolver() }; var jsonNetSerializer = new JsonNetSerializer(serializerSettings); GlobalHost.DependencyResolver.Register(typeof(IJsonSerializer), () => jsonNetSerializer); |
It looks good and everything run without a warning or error except that SignalR is no longer be able to connect to the server. I confirmed this by putting a breakpoint inside this function.
|
1 2 3 |
$.connection.hub.start().done(function () { … }); |
At first I did not realize the culprit was the camel case, so I try to dig deeper under the hood. I used the new diagnostic tool of IE11 to see what’s going on and compared with a previous version to see what’s going on. I could clearly see that the new version lack the 2 calls: connect and send although the negotiate when through successfully with a 200 response. (The first image was the SignalR calls in the new version and the second image was the SignalR calls in the old version)
I decided to dig even deeper into the negotiate response, and I found the culprit. The property names here suppose to be proper case, not camel (so it should be Url instead of url). So probably SignalR cannot interpret the response!
The solution
This problem was actually solved properly by several people.
The basic idea was to change the contract resolver but limit the effect of camel case to only classes external to SignalR. I tried the solution in the first link and it worked like a charm! It’s great to learn that today!