In hindsight to the created solution, there is an issue that cannot be addressed in this way: When a consumer fails to call Teardown properly at the right time for constructed objects, the DisposingSharedLifetimeManager will not behave as expected. For some, this may be a big issue, because it may not be very customary to bother to call Teardown when using Unity, precisely because it usually does nothing useful anyway.
Alternative Solutions Using Unity
One alternative is to use a wrapper of sorts and register that in the container instead. The usage would look something like this:
Two New Lifetime Managers
Having explained the issue, how can we solve it?
Before starting, I should mention that my implementation is based on previous work by Rory Primrose, who wrote an extension that changes the behavior of the TransientLifetimeManager in order to dispose of objects. He does an excellent job of explaining some of the rationale behind his implementation, so be sure to read his article.
I've placed the complete source code for my article (including some quick unit tests) on GitHub.
My approach is a little different: I did not want to change the default behavior of Unity, so instead I defined two new lifetime managers to explicitly set the desired behavior with: DisposingTransientLifetimeManager and DisposingSharedLifetimeManager.
This lifetime manager behaves pretty much like the built-in TransientLifetimeManager; every time a new object is created. The only difference is, that on Teardown of any object, we will call Dispose() on objects that were created as a result of the original build-up operation (provided they are using this lifetime manager, of course).
In modern software development, the use of Dependency Injection is a very important principle. It allows you to build large systems with properly decoupled and testable components. The use of Inversion of Control containers is a popular way of implementing Dependency Injection. If you are unfamiliar with these terms, this article probably isn't for you; I suggest you read Martin Fowler's excellent article about DI and IoC instead :)
In the .NET world there are probably dozens of different IoC containers available. They all serve the same basic need, but there are important differences in the features they offer. One popular IoC container is Unity, created by the Microsoft patterns & practices team.
Just because it's popular, doesn't mean Unity is perfect however. In this multi-part article, I will try to address some issues around classes implementing IDisposable in combination with Unity.