FeatureRequest: Allow changing default behaviour in builder

[YairHalberstadt]

Firstly, I would like to thank you for all your hard work on AutoFac - it is my favourite IOC container for .Net.

By default Autofac will hold onto any disposables it resolves till the end of a lifetime scope. If the LifeTimeScope is never or rarely ended, this will cause memory leaks.

This default doesn't work well for us - we would prefer that whenever we resolve a disposable which is instance per dependency, we are in control of disposing it, and Autofac does not hold on to the instance. If however the disposable is InstancePerLifeTimeScope or SingleInstance, we want Autofac to hold onto it and dispose it.

Currently this means we have to call ExternallyOwned on every registration.

It would be useful if it was possible to change these defaults, either through ContainerBuildOptions, or some other way.

Thanks

[tillig]

This pretty heavily overlaps with #481. At this time, while we might consider a PR for something like this, I don't think we'll be adding it ourselves. Tracking and managing disposals in lifetime scopes is pretty common for IoC containers. The majority of the times we've seen folks wanting to control all disposal for every component generally can be solved by breaking things up into smaller units of work and wrapping each of those units with its own lifetime scope.

I'm going to close this since it's not something the team is going to address, though again, we'd consider a PR for it. I'd prefer to not leave it open as one of the few multi-year-long issues that we will possibly never close because no one is actively handling it.

For future contributors interested in PR for this, things to consider:

• The container gets built at the root but child scopes may have registrations added. Do those fall under the same rules as the container or do they default to tracking disposables unless you override it?
• If someone using an integration package like the ASP.NET Core stuff turns off disposal and creates a huge memory leak for themselves inadvertently (because ASP.NET Core and the other application integration packages all assume the default behavior... yet the developer is responsible for building the container) how do we alert the developer so they can support themselves and troubleshoot without opening issues over here?
• ExternallyOwned and Owned<T> currently handle manual opt-out for disposal tracking. If someone defaults the container to not tracking disposables, how would they do manual opt-in for disposal tracking? What's the counterpart to ExternallyOwned and Owned<T> in this scenario?
• Assuming there's a counterpart to ExternallyOwned and Owned<T> what happens if someone wraps their component in both things? Let's say the counterpart to Owned<T> is Disposable<T>. (Bad name, but stick with it.) What if the component is registered as ExternallyOwned but someone injects a Disposable<T> of that component into their consuming class. Does it get disposed or not?

There's a lot of complexity around this to consider, these are just a few of the use cases that will need to be addressed if there's a PR for this. This is not an all-inclusive list, just stuff to get folks started.

[YairHalberstadt]

Thanks - I see the issue isn't as straightforward as I thought at first.

Is there any current workaround which would allow 'monkey patching' the builder and changing all existing registrations?

[tillig]

Nothing springs to mind, sorry.