1

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());

1 Answers1

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.

halter73
  • 15,059
  • 3
  • 49
  • 60
  • Would there be any downside to providing my own HubDescriptorProvider? –  Feb 12 '14 at 17:25
  • If you were to upgrade SignalR after the implementation of the ReflectedHubDescriptorProvider changes, your app wouldn't be taking advantage of the fixes/improvements to ReflectedHubDescriptorProvider unless you manually patch your custom IHubDescriptorProvider. – halter73 Feb 12 '14 at 18:40
  • Ok maybe I will try the same approach that the Ninject example had used and inherit the class so that it can fallback to the default usage. Thanks for your help. –  Feb 12 '14 at 19:10