Unity and ObjectBuilder Attributes With Same Name Can Cause Some Head Scratching

Feb 13, 2008 at 2:38 PM
Edited Feb 13, 2008 at 2:39 PM
I finally figured this out after 30 minutes of head scratching.

  [Dependency]
  public INewsService NewsService { get; set; }

Dependency is a valid attribute in at least 3 namespaces:

Microsoft.Practices.ObjectBuilder2
Microsoft.Practices.Unity
System.Runtime.CompilerServices


If one chooses anything but Microsoft.Practices.Unity, the dependency won't be added to the class.

I had accidentally chosen the namespace of Microsoft.Practices.ObjectBuilder2 and was wondering in bewilderment why the dependency was not being added to the class. Lesson learned, but I am wondering if this might mix a few people up given the ambiguity of the reference, at least with the ObjectBuilder and Unity Namespaces.

Regards,

Dave

________________________________________

David Hayden
Microsoft MVP C#
Feb 13, 2008 at 3:43 PM
Unfortunately all the good names are taken. The idea is to hide as much of ObjectBuilder as much we can from people. We only want people who are not extending to focus on the container and it's namespace. I can see if you have had experience with the others why the attribute would be a bit awkward. If you think we should change it... log an issue so others can vote.
Mar 22, 2008 at 4:22 PM
Hi David, Scott. I ran into the same problem and googled it to find this article. I need some guidance here because I'm new to Unity but I'm a long time fan of the MVP (wcsf) at least in this project, I'm trying to use the recipie's the correct way as much as possible.

So my question is to those of us using WCSF but want to move towards Unity, so I really want to try and mix the two IoC containers ? At first thought, I figured - sure they can co-exist, I can use the object builder 1.0 generated code for v-presenter logic and then I added a unity container (from Dave's example) to my global.cs and registered my unity ob2 services. Then I ran into the same namespace issue that you had and actually I'm still trying to figure out why my dependency code is not being called. I guess I need to try the Unity namespace - because I currently have Microsoft.Practices.ObjectBuilder2.Dependency and its not working.

I'm thinking that I may back out of using Unity until Ent Lib 4.0 and WCSF is rebuilt to use Unity. Do you have any idea how soon that might be ?

In terms of a vote - I would not change anything if Unity is going to replace object builder 1.0. But if this is a competeing IoC container then I would say make the attributes UnityDependencyUnityCreateNew or something. But I usually hate putting product names baked in code.


What would you do ?



DavidHayden wrote:
I finally figured this out after 30 minutes of head scratching.

  [Dependency]
  public INewsService NewsService { get; set; }

Dependency is a valid attribute in at least 3 namespaces:

Microsoft.Practices.ObjectBuilder2
Microsoft.Practices.Unity
System.Runtime.CompilerServices


If one chooses anything but Microsoft.Practices.Unity, the dependency won't be added to the class.

I had accidentally chosen the namespace of Microsoft.Practices.ObjectBuilder2 and was wondering in bewilderment why the dependency was not being added to the class. Lesson learned, but I am wondering if this might mix a few people up given the ambiguity of the reference, at least with the ObjectBuilder and Unity Namespaces.

Regards,

Dave

________________________________________

David Hayden
Microsoft MVP C#

Mar 22, 2008 at 5:57 PM
It is indeedMicrosoft.Practices.Unity.DependencyAttribute that you must use.

Both can co-exist. Ultimately, you just need to alias your namespaces.

You could also define a strategy that hooks one version into the other.

As for alternative names:

  • InjectedAttribute
  • InjectionAttribute

or even more specific:

  • InjectionPropertyAttribute
  • InjectionParameterAttribute

Personally, I tend to be fine with the names as they are right now and I'll probably use configuration as soon as we have the next drop so I won't care about attributes anymore.
Mar 22, 2008 at 6:05 PM
I see three options here.

  • Use a using statement to rename one or both attributes: using UnityDepedencyAttribute = Microsoft.Practices.Unity.Dependency;
  • Use the new Unity API instead of attributes to configure what gets injected.
  • Rip out the new strategies and replace them with the old OB2 versions and use the OB2 attributes.

Actually, that last one won't work, the attributes are still different.

There's no official plan on when or if WCSF will be updated to use Unity instead of OB1. A coworker is currently experimenting to see what it'll take, and it's working out very very well, but there's a lot of other things on the backlog in front of it.