Opt-in to captive dependency detection on a registration
See original GitHub issueMy company is using Autofac extensively and really loving it.
That being said, one of the most difficult to debug issue we have run into with IoC containers is captive dependencies.
I understand that captive dependencies are complex, and there are cases where captive dependencies are acceptable. However, we have cases where a component absolutely must not become a captive dependency (becomes its behaviour would be broken). We would like to be able to annotate these components so it is impossible for us to accidentally widen their lifetime scope without being notified by an error message.
I am imagining something like a LifetimeScopeCannotBeWidened
method that can be called when registering. The intention would be that, when this setting is applied to a registration, Autofac would throw an exception rather than inject the component into another component with a wider lifetime scope.
builder
.RegisterType<Component>()
.As<IService>()
.InstancePerLifetimeScope()
.LifetimeScopeCannotBeWidened();
Does that make sense? Do you think it would it be possible for us to extend Autofac to provide this functionality, or would this need to be built into Autofac?
Thanks for your help!
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:6 (3 by maintainers)
Hey @TylerReid, unfortunately I never found the time to investigate further, but a colleague recently pointed out that, at least for us, we could potentially use (or write) a library like the autofac-analysis project to detect issues like captive depedencies with our app as part of our integration tests. If you’re happy detecting issues at test-time, this could present a viable alternative that has the added benefit of not impacting the performance of the app.
Any sort of analysis like this will be a challenge to implement. Happy to see any PR, but if we’re going to support it, it really needs to be something folks can rely on if they use it. If it only handles a subset of cases, we will absolutely get more issues asking why it isn’t a 100% functional feature and it may become more maintenance burden than it’s worth.