UPDATE: The code in this post relates to SignalR v1. For an updated version that works for SignalR v2 check out this post.
I've been doing some work with SignalR recently. If you've not encountered SignalR before then take a look at the project wiki or Scott Hanselman's post to find out more.
By default, SignalR preserves the case of property names when sending objects from the server to the client. My preference is for PascalCase on the server and camelCase on the client, and in this post I'll show how you can achieve that.
To avoid breaking what seems to be a tradition for SignalR posts I'll start with a (very) basic chat-style application. I'm going to start with pretty much the same code as the hubs version of Scott Hanselman's post. I'm not going to spend much time breaking down the initial code so if you want more explanation then check out Scott's post.
This code creates a simple chat application. When the user clicks on the "send" button, the text from the "msg" input is sent to the SignalR Chat hub which then echoes it to all clients via the addMessage call. Clients register for this call and append the message to the "messages" list.
Aside from the functionality, there are a couple of things to point out here. Firstly, the hub is called "Chat" in the server-side code, but we refer to $.connection.chat to access it client-side. I use PascalCase server-side and camelCase client-side, so this all feels good to me. Simlarly, the hub has a "Send" method, and it is called from the client using "chat.send".
Then we get to the call from the server to the client, and we use "Clients.addMessage" on the server. To me this doesn't feel quite right. But it's not all bad as I can change this to "Clients.AddMessage" on the server and SignalR still allows the client to register with the "chat.addMessage" event. So far, so good!
The next step is to send some more data – suppose we want to send the timestamp for when the server received the message (or the originating user…).
This all works, but sometimes it makes more sense to group related data into an object.
As we've seen, for the most part SignalR is quite forgiving about casing, but when serialising objects it has to pick an option. Unfortunately (for me) it serialises the properties with the original server case. All is not lost - SignalR builds on top of JSON.NET, which has a lot of extensibility points for serialisation.
The code above automatically applies the case-conversion behaviour to all types in the same assembly as the Message class (and we can specify multiple assemblies if desired).
In this post we saw that SignalR allows us to use PascalCase on the server and camelCase on the client in most cases. When we're passing objects from the server the objects are serialised into JSON using the exact property names. We saw how we can use the JsonProperty to control this for individual properties on our classes, and we then looked at how we can create a contract resolver to instruct JSON.NET to convert the property names on serialisation.
Thanks for the code on fixing the casing. I turned it around to be a blacklist approach rather than whitelist. By adding the main signalr assembly to the blacklist I still get correct capitalisation for anon and dynamics, which is pretty useful.
Hopefully this is going to be fixed in signalr prior to 1.0?
Thanks! Saved me a ton of time.