Explicitly implemented property and method injection

Jul 21, 2009 at 2:14 PM

Is there a way to make them work with the current version of Unity (1.2)? For example, given the following types:

public class MyDependency

public interface IMyInterface
    MyDependency Dependency { get; set; }

public class MyClass : IMyInterface
    private MyDependency dependency;

    MyDependency IMyInterface.Dependency
            return dependency;
            dependency = value;
...i'd like to have a MyDependency instance injected into MyClass instance.
The following code:
IUnityContainer unity = new UnityContainer();
unity.RegisterType(new InjectionProperty("Dependency"));
IMyInterface o = unity.Resolve();
...fails at RegisterType with an InvalidOperationException, message "The type MyClass does not contain a property named Dependency.", thrown from InjectionProperty.AddPolicies. 
If I remove the InjectionProperty from the registration call and adorn either or both the property implementation and definition with a DependencyAttribute, MyClass instance is resolved, but the dependency is not injected. 
As mentioned in a similar thread, if I adorn the property definition with a DependencyAttribute and call BuildUp specyfing the explicitly implemented interface for the type, the dependency is injected, but it is a poor solution:
  • it forces the use of Unity attributes to specify dependencies,
  • it does so at the interface level (less acceptable than at the implementation level),
  • it requires a BuildUp call for each explicitly implemented interface.

Where would be the place to start to implement a workaround?

Dec 18, 2009 at 1:19 AM

I'll have to explore this more for a real fix. The current code is just doing a reflection call to type.GetProperty(name), which is obviously not returning the correct value. A cheap(ish) workaround would be to write a custom InjectionMember object that did reflection to grab stuff off the right interface, and then a resolver to fill in the value. I'm not sure how that would work with with code generated for the dynamic method though. Could be messy.

I'll see what I can do to get this addressed in 2.0.