Unable to inject Scoped/Transient services into FeatureFilter about featuremanagement-dotnet HOT 5 CLOSED

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.

from featuremanagement-dotnet.

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.

from featuremanagement-dotnet.

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

from featuremanagement-dotnet.

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

from featuremanagement-dotnet.

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

from featuremanagement-dotnet.