Skip to content
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

Add FAQ based on immutable container challenges #97

Open
tillig opened this issue Jan 27, 2020 · 6 comments
Open

Add FAQ based on immutable container challenges #97

tillig opened this issue Jan 27, 2020 · 6 comments

Comments

@tillig
Copy link
Member

tillig commented Jan 27, 2020

With Autofac 5 we removed ContainerBuilder.Update and containers are now immutable.

We should add an FAQ based on this discussion issue to help people understand alternatives to updating the container proper.

Also, we should make sure there aren't anymore doc references to ContainerBuilder.Update.

@natrexjacobs
Copy link

This may tie into #99 if the Update() removal is the root issue there?

@tillig
Copy link
Member Author

tillig commented Mar 3, 2020

This issue is more specifically to write a new article to explain how to work with immutable containers. I'll leave the other issue open so this one can be separately tracked.

@StefanoVuerich
Copy link

StefanoVuerich commented May 15, 2020

How can I add a registration to the global scope after build?

@alistairjevans
Copy link
Member

@StefanoVuerich; typically questions like that should be asked on Stack Overflow, rather than added as comments on existing issues.

That being said, the short answer is that, after Autofac 5.0, you cannot modify the global scope after it has been built. Child lifetime scopes can continue to have custom registrations within that scope. See https://autofaccn.readthedocs.io/en/latest/best-practices/#consider-a-container-as-immutable for some more detail.

@StefanoVuerich
Copy link

@alistairjevans
After googling a bit found that PreserveExistingDefaults works.
It it really the best solution to force people add a kind of "place holder object", that can be later on overrided?
Wouldn't be simpler to let the container have the possibility to add a new registration?

@alistairjevans
Copy link
Member

I'd recommend reading the content at the beginning of this thread for an explanation as to why it isn't simpler to allow a container update.

Placeholder objects aren't your only option; you can use delegate registrations, or organise your child scopes so you can change the dependencies per-scope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants