Disposal Order of Shared Dependencies in System.Composition

[thmrtz]

Hello there 😄 —
I am currently exploring System.Composition (v9.0.1) in a playground project and discovered an unexpected order of disposal for the parts created.

Let’s consider the following setup, where we want to obtain an instance of a Service:

class Service(IDependency dependency) : IService, IDisposable {}
class Dependency() : IDependency, IDisposable {}

The creation order for the parts is Dependency followed by Service, since Dependency is required for the construction of Service. On disposal of this composition container, we will discover the parts to be disposed in the same order as they are created (Dependency then Service).

To provide a possible example where this may be an issue — let's say for instance our Service is running a Task that will be cancelled on disposal, then there may be a race condition as its dependencies could already be gone and the relying service is still operational.

Granted, parts are generally not expected to still be used at the point the container is being disposed of — yet there may be scenarios where this is not as simple in the context of weak events.
Regardless, the order of disposal is unexpected to me and a reversed disposal order would seem more natural (and one could argue if that would mean more correct).

I am assuming that from an ownership perspective, the container is responsible for the disposal of the parts — particularly since the parts themselves have insufficient context, as their dependencies may be shared with others.

---

Could you help me understand if I am missing something, like a different lifecycle/ownership model?
Is there documentation or a consensus on why this was designed the way it is?

Thanks for your combined insight 😄

[thmrtz]

@jeffhandley Could you kindly point me to someone who can be of assistance?