Inject dependencies into SignalR hub method

[Daniel15]

Is there a way to inject dependencies into a SignalR hub method, similar to how we can use FromServicesAttribute with ASP.NET MVC to inject a service into an action method? I tried just listing the dependency in the method signature but got an error "Failed to invoke foo due to an error on the server"

API

public class HubOptions
{
+    public bool DisableImplicitFromServiceParameters { get; set; }
}

Alternative names

EnableImplicitFromServiceParameters
InferFromServiceParameters
InferParametersFromService(s)

Additional thoughts

Instead of opt-in, make the option an opt-out and attempt to detect services by default. (This would likely require a breaking change announcement)

[davidfowl]

No there isn't. It's something we could look at in the future though.

[halter73]

FWIW, the lifetime of the hub is typically only the duration of a Hub method invocation. I think the same is true for Controllers and Actions for that matter. So ctor injection might not look as nice, it should work more or less the same.

[Daniel15]

The issue is if each hub method requires different dependencies, you end up with a giant constructor, and may construct dependencies that aren't actually needed by the method that's being called. :)

I haven't tested but I guess injecting the IServiceProvider into the constructor would work, then I could use that or ActivatorUtilities in the hub method.

[halter73]

I haven't tested but I guess injecting the IServiceProvider into the constructor would work, then I could use that or ActivatorUtilities in the hub method.

That should definitely work, but I understand that's far from ideal.

[erikmf12]

@Daniel15 - I know this doesn't solve your problem, but it might help to use partial classes for your hub class. You could have your constructor in a MyHub.Constructor.cs and all other methods in a different MyHub.ClientMethods.cs.

[davidfowl]

Maybe we can support this better now that we have synthetic arguments (like cancellation tokens).

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[davidfowl]

We need to define a [FromServices] attribute lower in the stack that can be used by SignalR. The one in MVC is well tied to MVC.

[BrennanConroy]

api-suggestion?

[halter73]

I hate having multiple [FromServices] attributes. Type forwarding and still needing using Microsoft.AspNetCore.Mvc; doesn't seem great either though.

I wonder if we could infer the parameter is a service without an attribute? Even if we could, we'd probably still want an attribute. 😢

[BrennanConroy]

We also need a way to allow opting out of services per parameter or per method.
e.g. [FromClient], [FromInvocation], [FromCall]

Or, only DI inject if [FromServices] is on the parameter.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[pranavkm]

API review:

API approved. We spoke about this and think this should be an opt-out feature. We discussed the name and think DisableImplicitFromServiceParameters (using implicit over inferred) is better.

public class HubOptions
{
+    public bool DisableImplicitFromServiceParameters { get; set; }
}

[BrennanConroy]

Was the breaking change nature discussed? We probably need to make an announcement if we make it opt-out.

[halter73]

I think I mentioned how unlikely I feel this was to break people 😆 Making an announcement is a good idea though.