Unable to inject Scoped/Transient services into FeatureFilter

[artyom-p]

In.NET Core 3.0 DI scope validation is enabled by default.
Application throws an exception that it is not possible to resolve service that is Scoped/Transient .

Cannot consume scoped service 'Common.Services.IRequestDataProvider' from singleton 'Microsoft.FeatureManagement.IFeatureFilter'

[jimmyca15]

Is this different from existing behavior? I wouldn't expect a scoped service to be able to be used in the feature filters which are singletons. This is why things like IHttpContextAccessor services exist which give a way to access the scoped HttpContext.

[jimmyca15]

Closing since there has been no response. Please re-open if my response is inadequate.

[cbrianball]

I ran into this issue yesterday. I managed to code around it, but it was less than ideal.

I ran into two primary issues:

1. I inject the current user via an interface I've created.
2. I was unable to inject my EF Core database context (and even if I could, there could be potential issues as EF Core DB Context is not meant to be run on multiple threads).

For the first issue, a web project could inject IHttpContextAccessor, but my code is in a shared library that is used by both a web project and non-web projects. I worked around this by creating a type that functions similarly to HttpContextAccessor, but for my interface that describes the current user instead.

I could have passed the user object into the feature manager method as a context, but then the calling code would need to know that the configured feature filters would need to act on the current user, and I don't believe that's a good idea.

For the second issue, I ended up injecting IServiceProvider into my feature filters that need to access the database. This is a hack, in my opinion, and I hope to find another solution in the near future.

Both of these could have been avoided if the registered feature filters were not singletons (either scoped or transient would have sufficed).

The code-base seems pretty straight forward, but I don't want to make any bad assumptions. If you can give me some general direction (or at least tell me what you are trying to avoid), I can work on a PR to allow feature filters to not necessarily be singleton.

[szalapski]

I am hitting this too. I wish it could depend on a scoped ISessionManager.

[zhiyuanliang-ms]

I ran into this issue yesterday. I managed to code around it, but it was less than ideal.

I ran into two primary issues:

1. I inject the current user via an interface I've created.
2. I was unable to inject my EF Core database context (and even if I could, there could be potential issues as EF Core DB Context is not meant to be run on multiple threads).

For the first issue, a web project could inject IHttpContextAccessor, but my code is in a shared library that is used by both a web project and non-web projects. I worked around this by creating a type that functions similarly to HttpContextAccessor, but for my interface that describes the current user instead.

I could have passed the user object into the feature manager method as a context, but then the calling code would need to know that the configured feature filters would need to act on the current user, and I don't believe that's a good idea.

For the second issue, I ended up injecting IServiceProvider into my feature filters that need to access the database. This is a hack, in my opinion, and I hope to find another solution in the near future.

Both of these could have been avoided if the registered feature filters were not singletons (either scoped or transient would have sufficed).

The code-base seems pretty straight forward, but I don't want to make any bad assumptions. If you can give me some general direction (or at least tell me what you are trying to avoid), I can work on a PR to allow feature filters to not necessarily be singleton.

This issue should be re-opened. @jimmyca15 @cbrianball @szalapski

[zhiyuanliang-ms]

Update:
The PRs of exposing FeatureManager to public and adding AddScopedFeatureManagement() method have been merged into main branch.
More detailed discussion can be found in #258
The plan is to release these updates in 3.1.0

Now, we provide AddScopedFeatureManagement() method which will register FeatureManager and feature filters as scoped services. In this way, you can inject scoped services into feature filters.

Also, we expose FeatureManager to public, you can also register the feature management system as transient by yourself.

[zhiyuanliang-ms]

Fixed in release 3.1.0