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).
I have spent a considerable amount of time on development in a service-oriented architecture. On the Microsoft platform, the technology of choice is WCF (Windows Communication Foundation). Generally, it is a great technology, but it does have its nuisances. One of them is the way certain error conditions are handled when consuming web services.