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

Difference in CreateChildContainer when cloning multiple of the same type vs one. #15361

Closed
Jetski5822 opened this issue Feb 19, 2024 · 6 comments

Comments

@Jetski5822
Copy link
Member

Describe the bug

When cloning services using CreateChildContainer we have a difference in behaviour between cloing multiple of the same service (see:

else if (services.All(s => s.Lifetime == ServiceLifetime.Singleton))
) to if we were cloning just the one (see: )

The big difference here is that one uses the implementation factory and the other doesnt.

Is there a reason we do this? and should it all be going through the same process regardless of if its one or not...

@hishamco
Copy link
Member

Nice to see @Jetski5822 shine again :)

@Piedone
Copy link
Member

Piedone commented May 21, 2024

Is this causing any issue, or does it surface some discrepancy?

After JT's passing, paging the only person who was there at the time: @sebastienros.

@Piedone Piedone added this to the backlog milestone May 21, 2024
@gvkries
Copy link
Contributor

gvkries commented May 29, 2024

This line also looks very suspicious, the created scope is never used:

@gvkries
Copy link
Contributor

gvkries commented May 29, 2024

Because I was working on the shell container factory recently, I took a quick look. If I understand this code correctly, it is an optimization if there is a single service only. In that case, if the result is not disposable, creating the singletons can be deferred until a tenant resolves them. Otherwise all services must be created immediately.

So I think this should be kept, but the code is hard to understand. Maybe we can simplify it little bit.

Copy link
Contributor

It seems that this issue didn't really move for quite a while despite us asking the author for further feedback. Is this something you'd like to revisit any time soon or should we close? Please reply.

@github-actions github-actions bot added the stale label Jun 17, 2024
Copy link
Contributor

Closing this issue because it didn't receive further feedback from the author for very long. If you think this is still relevant, feel free to reopen it with the requested details.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants