9

Unity 2.0:

By default RegisterInstance uses the ContainerControlledLifetimeManager. When the Unity container is disposed, it calls Dispose on the instance (if IDisposable).

In my case that's not what I want. The instance is owned by and disposed by another class; Unity should just inject the reference. So I used:

container.RegisterInstance(instance, new ExternallyControlledLifetimeManager());

The Unity documentation (under Understanding Lifetime Managers) states:

Using the RegisterInstance method to register an existing object results in the same behavior as if you just registered the lifetime container with RegisterType. Therefore, it is recommended that you do not use the RegisterInstance method to register an existing object when using the non-default lifetime managers except for the thread in which the RegisterInstance was invoked.

What does this mean?

The same section also states:

If you registered an existing instance of an object using the RegisterInstance method, the container returns the same instance for all calls to Resolve or ResolveAll or when the dependency mechanism injects instances into other classes, provided that one of the following is true:

  • You have specified a container-controlled lifetime manager
  • You have used the default lifetime manager
  • You are resolving in the same context in which you registered the instance when using a different lifetime manager.

I tried resolving in a different thread after using RegisterInstance with ExternallyControlledLifetimeManager, and it worked - I got the singleton instance.

My code matches an example in the Creating Instance Registrations section. I want to make sure I understand the context caveats, though.

To be clear, I always want the Unity container to inject the instance I registered regardless of thread, etc. and I do not want Unity to dispose of it. Am I doing this correctly?

shenku
  • 11,969
  • 12
  • 64
  • 118
TrueWill
  • 25,132
  • 10
  • 101
  • 150
  • 1
    Related: http://stackoverflow.com/questions/5129789/unity-2-0-and-handling-idisposable-types-especially-with-perthreadlifetimemanage – Mark Seemann Mar 16 '11 at 19:36

2 Answers2

5

Be aware of ExternallyControlledLifetimeManager. You must still hold the reference to the instance somewhere outside of the container. Once you lose the reference you can lose the instance because ExternallyControlledLifetimeManager holds only WeakReference. If you don't have normal reference Garbage collector can collect your instance. Check example on my blog.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • I wish I could accept both answers. @zespri addressed my question specifically, but your blog entry is excellent. – TrueWill Mar 17 '11 at 14:26
2

I think you are good. All the per-thread comments only matters when you are using PerThreadLifetimeManager, which you are not using. It's just clumsy wording on the MSDN article part.

This is not a standard terminology, but in this article by context they mean something defined by a particular life time manager. For PerThreadLifetimeManager your context is your thread. For HierarchicalLifetimeManager your context is a particular container in your container hierarchy.

For ExternallyControlledLifetimeManager there is no particular context, so you can ignore the note in question completely.

As a side note, make sure that you don't dispose your instances while you still expect the container to resolve them. If you do, your resolve request will either return a different instance than you expected, or throw an exception, depending on whether the container can construct your type or not.

Andrew Savinykh
  • 25,351
  • 17
  • 103
  • 158