Prevent singletons with container-scoped dependencies

[julian99m]

... by passing singleton-information within the resolution context and checking it during resolution.

Conceptually, singletons should not use container-scoped dependencies.
I can not think of any use case where the previous behavior (initializing a singleton that uses one specific instance of a container-scoped dependency) would be useful. In fact, it could lead to hard-to-detect bugs by using unexpected instances.

As this could be a breaking change, it might be necessary to have the change only be activated by configuration. Please give me feedback in that regard :)

[julian99m]

@microsoft-github-policy-service agree company="freenet DLS GmbH"

[Xapphire13]

Is the bug/undefined behavior we're trying to prevent, the scenario where a child container instantiates a parent container's singleton, which now has a dependency scoped to the child container?

[julian99m]

Is the bug/undefined behavior we're trying to prevent, the scenario where a child container instantiates a parent container's singleton, which now has a dependency scoped to the child container?

basically, yes. I'd say the issue is not limited to parent/child-containers, but generally to singletons using container-scoped dependencies. But the scenario you described is probably the most common one where this happens.

[julian99m]

Wait, now you got me thinking... parent container instances using child container instances is not a subset of singletons using container-scoped dependencies. Instead, they are separate scenarios that can overlap (because singletons are registered in the global container).
Regarding the expected behavior, I am unsure if parent container instances using child container instances should also be prevented, or if there are valid use cases for that behavior. Anyhow, this scenario is not covered by my current changes.

[julian99m]

Any opinions on this topic?

[julian99m]

bump

[julian99m]

bump

[julian99m]

bump

[julian99m]

@Xapphire13 any feedback on this?