The problem is that there is no way for a client class to know if an injected dependency is IDisposable (without using reflection, which is not acceptable). Instead, the IOC containers themselves implement IDisposable and use reflection to determine which
created / provided objects are IDisposable. Thats good. However, the Unity container doesn't keep track of most objects it creates - which makes calling Dispose() on the Unity container near useless. Other containers, such as Windsor and
Autofac, keep track of *all* IDisposable objects they make / contain. But there is still a problem. Calling Dispose() on those containers effectively ends the lifecycle of the container, which leaves the client orphaned from further IOC
access. To compensate, the application code will often post-pone calling Dispose() on the container as long as possible - the opposite of what normally would be designed and coded.

If there is something I'm completely misunderstanding, please explain. Otherwise, I'm hoping someone can discuss strategies that minimize this problem. Until that time, some solutions I'm considering are:

2) If using TDD / IOC containers, then adhere to both:
a) Don't use Unity (use AutoFac or Windsor instead, because they track every single IDisposable object they make).
b) Never Resolve() on the parent container directly. Instead, every recipient of the parent immediately makes a child container(s) and calls resolve on that instead. When finished, the client always calls Dispose() on the child container.
So if there were any IDisposables created, they are freed quickly.

My above solution #2 ASSUMES that the child container tracks objects provided by Resolve(), even though the Register() may have been made on the parent container.