Skip to content
This repository has been archived by the owner on Nov 2, 2018. It is now read-only.

How to dispose top-level IServiceProvider #338

Closed
khellang opened this issue Dec 16, 2015 · 8 comments
Closed

How to dispose top-level IServiceProvider #338

khellang opened this issue Dec 16, 2015 · 8 comments

Comments

@khellang
Copy link
Contributor

Since IServiceProvider doesn't implement IDisposable, and ServiceProvider (which does implement it) is internal, how are you supposed to dispose a "top-level service provider", i.e. the result of calling IServiceCollection.BuildServiceProvider()?

I could of course do a (provider as IDisposable)?.Dispose(), but it would be nicer if the interface implemented IDisposable. That way it would work better with generic constraints etc.

I understand that there's little to do with the interface itself, since it's an old interface that's been reused, but would it be possible to add a separate one?

Something along the lines of

namespace Microsoft.Extensions.DependencyInjection
{
    public interface IServiceProvider : System.IServiceProvider, IDisposable { }
}

I think I've gotten around the problem by immediately creating a scope, which is disposable, and use its provider, but I don't think it's a good solution.

What was the reasoning for using the existing interface? And why is everything internal? 😝

@Eilon Eilon added this to the Backlog milestone Jan 23, 2016
@Eilon
Copy link
Member

Eilon commented Jan 23, 2016

Moving this to Backlog as we are not planning to make any changes for this at this time.

@khellang
Copy link
Contributor Author

What about an answer and/or close it instead?

@davidfowl
Copy link
Member

aspnet/Mvc#3726 (comment)

Nope 😄

@khellang
Copy link
Contributor Author

I don't get it. Is that the answer? How does that relate to this?

I don't really care about the interface, but there has to be some way to get a hold of the concrete type to call dispose on it, without resorting to casting etc.?

@Eilon
Copy link
Member

Eilon commented Jan 25, 2016

Yeah not sure what @davidfowl is talking about there...

But the answer for now is that unfortunately we don't have a good answer on this. I think creating a scope immediately is an acceptable workaround in the meantime. This is certainly something we can reconsider.

@davidfowl
Copy link
Member

We'd have to expose the concrete type (which we were trying to avoid) from BuildServiceProvider

@davidfowl
Copy link
Member

@Eilon we can consider this for 2.0. Make a breaking change to the return value of BuildServiceProvider and make the internal ServiceProvider public.

@Eilon Eilon removed this from the Backlog milestone Feb 19, 2017
@Eilon
Copy link
Member

Eilon commented Feb 19, 2017

Let's do another fun DI triage 😄

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

3 participants