Container TearDown behavior

May 30, 2010 at 4:59 AM

Hi guys,

I've written a build strategy that disposes IDisposable types created by the container when TearDown is invoked. I was expecting that the container would clean up all objects related to the object being destroyed, but it seems to only clean up the actual instance passed to TearDown. In my test scenario, objects created by the same container and passed in as a constructor parameter or injected via a property do not get cleaned up.

Is there a way to get the BuilderStrategy to be invoked for all these objects?

May 30, 2010 at 6:39 AM

You'll have to implement that kind of behavior yourself. TearDown out of the box does nothing, it's a hook for extensions that want to implement explicit cleanup behavior.


May 30, 2010 at 6:54 AM

Yep, already done that. My BuilderStrategy is only getting called for the instance passed into TearDown though. I was assuming that it would get called for each instance created in the BuildUp of that object.

I think where I need to head now is to track each item that gets created in the BuildUp of an instance and then use that knowledge in its tear down. Does that sound like I'm on the right track?

May 30, 2010 at 8:27 PM

You are correct. Unity doesn't track the entire build tree for an object; in addition you could theoretically pass in an object with dependencies that wasn't created by the container. So yes, you'll need to figure that out and recursively tear down dependencies in your builder strategy.


May 31, 2010 at 1:12 AM

I've done a decent amount of Reflector surfing to figure out what's going on and there doesn't seem to be an obvious way to link build operations for each object.

For each object I can get the instance (Existing) from the builder context and its BuildKey and OriginalBuildKey. If I store the instance created (presumably as a weak reference) and its keys then on tear down I will be able to calculate all the related build keys from the set of persisted policies (property and constructor injection keys). 

Unfortunately there doesn't seem to be a way to track a link between the instances created as belonging to the same BuildUp process. Each instance created on BuildUp has it's own context instance so there is no link from that angle. Without this link I wouldn't know which instance to dispose given a set of objects with the same build key (created by multiple Resolves or BuildUp invocations for the same build key).

Any ideas on how to track objects created within a single BuildUp operation?

May 31, 2010 at 1:21 AM

I should clarify. As you have suggested, I can't just reflect over the object on tear down because there might be objects pinned to it that were not created by the container. Even with properties decorated with the Dependency attribute do not mean that the instance on the property was created by the container as it could have been provided another instance after BuildUp. Reflecting the instance also wouldn't take into account constructor injected instances that are not exposed as properties (or worse, not even stored in the object). The only way to correct tear down the instances is to track the build tree on BuildUp.

BTW, my current logic that disposes the tear down instance checks the lifetime managers to see if any manager is still storing a reference to the instance on tear down. If this is the case then the instance is not disposed as it is still "alive". I am assuming this is correct logic.


May 31, 2010 at 6:01 AM

I think I've just got a solution working. I am using several BuilderStrategies over Setup, Create and PostInitialize stages. On Setup, I determine whether there is a NamedTypeBuildKey for the thread. If not, I take the context.BuildKey as the key for the build session. I then track all items created in the Create stage for that thread and then ditch the build session key on PostInitialize when the context identifies the same build key that started the BuildUp process.

This seems to accurately track all items created for the same top level instance. The only risk I can see with this is if different parts of the build session were executed on different threads, however I think this is unlikely.

Now I just need to identify the build tree for a tear down instance, check each item in the build tree for items that still exist (WeakReference), are IDisposable, do not exist in a ILifetimePolicy.GetValue where the same conditions are true for all their children. Those will be the items I can then dispose.

Ha, I thought this would be easy... :)

Jun 18, 2010 at 5:08 AM

FYI, I've finished my unity extension for disposing build trees on TearDown.

I've blogged about it at