Is is possible to use a custom resolver instead of the hubname attribute to resolve signalr hubs?

Question

All of my SignalRHubs have their own service interface, this is used on the client side for type safe calling; ie no more referring to methods by string.

Anyways with this setup I have had to add a HubName attribute to all my hubs with the Interface name. Is it even possible to have the hubs resolved by these interfaces.

I did try replacing the resolver both in GlobalHost and in the HubConfiguration object with a Ninject resolver but it didn't seem to ever call the resolved for the hubs themselves.

Here is an example of a hub:

[HubName("IFoobarService")]
public class FoobarHub : Hub, IFoobarService
{
    public void Baz(BazDto dto)
    {
        Clients.Others.Baz(dto);
    }
}

}

Here is the code I used to try to bind my hubs with Ninject kernel.Bind(x => x.FromThisAssembly() .SelectAllClasses() .InheritedFrom() .BindAllInterfaces());

Answer 1

I think that using the HubName attribute is your best bet.

You could provide your own IHubDescriptorProvider and register it with SignalR's DependencyResolver, but I wouldn't recommend it.

You can take a look at the default IHubDescriptorProvider implemenation here: https://github.com/SignalR/SignalR/blob/2.0.2/src/Microsoft.AspNet.SignalR.Core/Hubs/Lookup/ReflectedHubDescriptorProvider.cs#L56

Notice the following line of code:

var hubDescriptors = types
    .Select(type => new HubDescriptor
                    {
                        NameSpecified = (type.GetHubAttributeName() != null),
                        Name = type.GetHubName(),
                        HubType = type
                    });

Type.GetHubName() is implemented as an extension method here:

https://github.com/SignalR/SignalR/blob/2.0.2/src/Microsoft.AspNet.SignalR.Core/Hubs/Extensions/HubTypeExtensions.cs#L9

You could replace the ReflectedHubDescriptorProvider with your own IHubDescriptorProvider implementation that calls into your own GetHubName method, but I think that would be overkill.

Once again, I think using the HubName attribute is your best bet.