Skip to content

Respect ServiceLifeTime during resolution #36050

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
alexanderjung-sdxag opened this issue Feb 21, 2020 · 4 comments
Closed

Respect ServiceLifeTime during resolution #36050

alexanderjung-sdxag opened this issue Feb 21, 2020 · 4 comments

Comments

@alexanderjung-sdxag
Copy link

Currently it is not possible to register a service interface scoped and singleton with different implementations, e.g.

services.AddSingelton<IMyInterface, GlobalEngine>();
services.AddScoped<IMyInterface, ScopedEngine>();

A call to "sp.GetService()" on the global service provider will either raise
an exception ("InvalidOperationException: Cannot resolve scoped service '{0}' from root provider.")
or resolve ScopedEngine, depending on ServiceProviderOptions.ValidateScopes.

Also I have no way of working around that issue, since there is no way to ask the IServiceProvider whether it is scoped or not.

Best solution would be, if a resoluton on the global service provider ignored scoped definitions.
Next best solution would be some way to determine if the current solution provider is scoped or not.

PS: I realize that this is a corner case and I'm usually fine with restrictions - as long as I can find workarounds.

@davidfowl
Copy link
Member

It's pretty much a corner case, best we could do is add a flag to turn it off bu ti's pretty low priority and we have no plans to change the default behavior. What are you expecting the behavior to be here?

@alexanderjung-sdxag
Copy link
Author

I realize that changing the logic for resolve may be "none-trivial".

That's why I mentioned a way to determine if the current solution provider is scoped or not. This seems to have been considered at some stage, as CallSiteKind already has an enumeration "Scope". Having the service provider return the current scope when resolving IServiceScope (like VisitServiceProvider does for IServiceProvider), and including something like IsRoot or GetParentScope() in IServiceScope.

However...
Thinking about possible solutions, I actually found my workaround. In case anyone runs into the same issue, here is a simple example:

        // IMyInterface should be resolved scoped AND globally!
        public interface IMyInterface { string Which { get; } }
        public interface IScopedMyInterface : IMyInterface { }
        public interface IGlobalMyInterface : IMyInterface { }

        public class MyClass : IScopedMyInterface, IGlobalMyInterface
        {
            public string Which { get; set; }
        }

        public class RootServiceProvider
        {
            public IServiceProvider ServiceProvider { get; }

            public RootServiceProvider(IServiceProvider serviceProvider)
            {
                this.ServiceProvider = serviceProvider;
            }
        }

        [TestMethod]
        public void TestMethod1()
        {
            var sp = new ServiceCollection()
                .AddSingleton<RootServiceProvider>()
                .AddSingleton<IGlobalMyInterface>(_ => new MyClass { Which = "Global" })
                .AddScoped<IScopedMyInterface>(_ => new MyClass { Which = "Scoped" })
                .BuildServiceProvider();

            var scope = sp.CreateScope();

            Assert.AreEqual("Global", GetMyInterface(sp).Which);
            Assert.AreEqual("Scoped", GetMyInterface(scope.ServiceProvider).Which);
        }

        private IMyInterface GetMyInterface(IServiceProvider sp)
        {
            var root = sp.GetRequiredService<RootServiceProvider>();
            var current = sp.GetRequiredService<IServiceProvider>(); // get internal engine!
            if (root.ServiceProvider == current)
                return sp.GetService<IGlobalMyInterface>();
            return sp.GetService<IScopedMyInterface>();
        }

That can surely be optimized, but the gist ist there.

@analogrelay analogrelay transferred this issue from dotnet/extensions May 7, 2020
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-System.ServiceProcess untriaged New issue has not been triaged by the area owner labels May 7, 2020
@analogrelay analogrelay added this to the Future milestone May 7, 2020
@ericstj ericstj removed the untriaged New issue has not been triaged by the area owner label Jun 18, 2020
Copy link
Contributor

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

@dotnet-policy-service dotnet-policy-service bot added backlog-cleanup-candidate An inactive issue that has been marked for automated closure. no-recent-activity labels Apr 14, 2025
@davidfowl davidfowl pinned this issue Apr 14, 2025
@davidfowl davidfowl unpinned this issue Apr 14, 2025
Copy link
Contributor

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.

@dotnet-policy-service dotnet-policy-service bot removed this from the Future milestone Apr 28, 2025
@github-actions github-actions bot locked and limited conversation to collaborators May 29, 2025
@dotnet-policy-service dotnet-policy-service bot removed no-recent-activity backlog-cleanup-candidate An inactive issue that has been marked for automated closure. labels May 29, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants