Interface Forwarding Resolution Issue

Jun 30, 2010 at 5:01 PM
Edited Jun 30, 2010 at 5:02 PM
I have searched the message archive and the Internet, but cannot find the resolution to this issue.

Is Unity not smart enough to understand forwarding of type rules? The example below crashes for me with InvalidOperationException "The current type, ISomeInterface, is an interface and cannot be constructed"

        public interface ISomeForwardedInterface { } 
public interface ISomeInterface : ISomeForwardedInterface { }
public class SomeInterfaceImplementer : ISomeInterface { }

unityContainer.RegisterType<ISomeInterface, SomeInterfaceImplementer>(new ContainerControlledLifetimeManager());
unityContainer.RegisterType<ISomeForwardedInterface, ISomeInterface>(new ContainerControlledLifetimeManager());
var someForwardedInterface = unityContainer.Resolve<ISomeForwardedInterface>();

If I change the registration to register ISomeForwardedInterface to SomeInterfaceImplementer, everything works, but does this mean that type registration must be to a concrete type? I haven't seen this documented anywhere. And if so, why doesn't the register method throw if the "to" type is an interface? The only error is at resolution time.

Thank you in advance for any help.
Jul 1, 2010 at 12:03 AM

Type registration is one step only. This is by design.

You could map an interface to an interface, which was then mapped to a registered instance, so it's not alway an error to register to an interface.


Jul 2, 2010 at 2:13 PM
Edited Jul 2, 2010 at 2:13 PM
OK, thank you very much for the clarification and the quick response.

I think it's interesting that there's so much talk of swapping out container implementations, but really there are key differences such as this that make it difficult to switch. This behavior, for example, is different from StructureMap, which is what I normally use. I'm also not crazy about making a new instance of a lifetime manager for each singleton type, instead of just passing in a bool flag. But I like other Unity traits better, like the way it's configured, so I guess there are always tradeoffs. Thanks.
Jul 2, 2010 at 9:26 PM

I think the discussion about swapping out containers is being picked up too broadly. If you're writing an application, there's no reason to be container independent in my opinion. Just pick one and use it. Where container independence is important is in libraries and frameworks. As a library author, I'd like to take advantage of DI as well, but I need to be very careful not to force MY choice of container on the users of my framework.

Jul 12, 2010 at 1:33 PM
I disagree that there's no need to be container independent in apps. I'm starting a new app, and would like to take advantage of Prism in it, while reusing a lot of my old classes from an internal library. If I haven't gone through the effort of centralizing its DI logic, I would've had StructureMap references all over the place, and could not just reuse the classes. Now I have new logic that interprets my own attributes instead of StructureMap's ones, and makes the appropriate Unity configuration calls. I think it was worth the effort.

Libraries don't necessarily have to be for external consumption, and it's always a good idea to minimize their dependencies. I think the next one I'm going to get rid of is log4net. I like Prism's concept of a logging facade, but don't like its interface enough to use directly.
Jul 13, 2010 at 5:50 AM
I generally have the opinion that if you're doing DI correctly, you're not actually touching the container much except at application startup anyway, so it's not as much of an issue in a properly designed application.