SignalR

Client – Server Event aggregation with Role Authorization

I’ve covered my SignalR Event aggregation library in an earlier post found here. That library has a Constraint API so that you can control which events a specific user should receive. It requires you to write one constraint handler for each type of event. But how about standard declarative Role Authorization?
(more…)

Advertisements

Client – server event aggregation with SignalR

Event aggregation is really a pattern i like, there is something elegant about firing events and subscribers can listen to them without knowing who fired them. This creates decoupled domains both in backends and frontends. At my latest customer we saw an increasing demand for pub / sub and immediate update. We fired events on the backend event bus and in the frontend we had SignalR Hubs that picked up the events and forwarded them to the clients. This caused duplicated and similar code both on the client and on the web server. I decided to create an abstraction layer between SignalR and the event aggregator. The result is a library called SignalR.EventAggregatorProxy

(more…)

Why overriding JsonSerializer no longer work in SignalR 2.0

I see almost everyday people having problem with overriding JSON serializer settings in SignalR. In SignalR 1.x they used an interface, IJsonSerializer, that you could override to set the JSON settings. In SignalR 2.x they instead use a concrete type JsonSerializer.

Ninject

The problem starts if you use a dependency injection framework like Ninject. The Dependency resolver that most people use for Ninject together with SignalR is doing this to get a type.

return kernel.TryGet(serviceType) ?? base.GetService(serviceType);

In SignalR 1.x this worked because when Ninject is doing TryGet on an interface it will return null and instead call base.GetService which in turn will use the type registered with SignalR’s internal IoC (GlobalHost.DependencyResolver).

In SignalR 2.x this will no longer work because we are now using a concrete type and Ninject will create instances of unregistered concrete types without complaining. base.GetService will never be called and the types registered in GlobalHost.DependencyResolver will not be used.

Remedy

One way of solving this is to register the JsonSerializer with the Ninject kernel instead of register it with GlobalHost.DependencyResolver.Register

The other is to check if the type is registered with Ninject, if it is use kernel.Get otherwise use base.GetService. This can be done like

kernel.GetBindings(serviceType).Any();