Closed GoogleCodeExporter closed 8 years ago
The issue you describe is why we have documented on the best practices wiki
page that you should always resolve dependencies from nested lifetime scopes:
https://code.google.com/p/autofac/wiki/BestPractices#Always_Resolve_Dependencies
_from_Nested_Lifetimes
One way you can fix this for your components that must be IDisposable but
resolved from the root container is to mark them ExternallyOwned. That's on the
wiki here:
https://code.google.com/p/autofac/wiki/DeterministicDisposal
Alternatively, as you found, you can use the Owned<T> relationship to
automatically disable the tracking.
Using DI and properly configuring it is a somewhat advanced thing that is
really hard to help people "stop shooting themselves in the foot." We can't
anticipate whether you'll be resolving an IDisposable component from the root
of the container. We don't know if you're building a temporary container and
it's OK to allow you to resolve references to singleton IDisposables right out
of the container. There are numerous other situations where you can also get
into a sticky place if you're not careful. (Create a nested lifetime scope and
forget to clean it up?)
Unfortunately what that all amounts to is that there's no great way to add
"sanity checking" like this. We have to trust that the application developer is
doing proper memory management, lifetime scope management, and so forth.
I'm glad you caught the issue in your app, but I don't think we'll be
implementing safeguards around this.
Original comment by travis.illig
on 4 Jan 2014 at 12:06
Did you consider the solution of using WeakReference in the implementation of
the Disposer? It seems like would resolve the issue without any change to the
API.
Original comment by mike.ade...@gmail.com
on 6 Jan 2014 at 1:03
Yes, I did consider that. The concepts in this issue fairly strongly overlap
with Issue #397, "Nested lifetime scopes aren't disposed when the parent is
disposed":
https://code.google.com/p/autofac/issues/detail?id=397
Just switching to WeakReference doesn't fix it; it changes fundamentally the
way you need to track activated instances and clean up after them. It adds a
lot of complexity overall and from a cost/benefit standpoint isn't necessarily
worth it. Check out the chain in issue #397 for some insight there.
We are looking at a lot of different ways to update the internals of Autofac
for future releases - from performance to functionality - and may fix this as a
byproduct of those improvements, but for now we're not looking to switch this
up.
Original comment by travis.illig
on 6 Jan 2014 at 3:39
Original issue reported on code.google.com by
mike.ade...@gmail.com
on 3 Jan 2014 at 10:56