patterns & practices - Unity

Just wanted to let folks know that I've just uploaded our latest work on Unity to Codeplex source control (the Source Code tab above). This represents the first real work we've done on Unity as part of the Entlib 5.0 effort.

There's two major updates in this drop. First, the ObjectBuilder2 DLL is now gone. The code is now completely contained in the Unity assembly, and you won't need to reference OB2 anymore in your projects using Unity. Over time the ObjectBuilder stuff is going to lose a lot of it's generality and be just the underpinnings for the container.

Second, we're taking a first cut at fixing our horrendous exception messages. All the extra "BuildFailedException"s that ended up in the inner exception tree are now GONE. Instead, you get a top level ResolutionFailedException, and the InnerException is the actual exception that caused resolution to fail. And the exception message has been reformatted significantly to hopefully get a better description of what the container was doing, and how it ended up where it did, when the error occurred. I'm hoping this is a significant improvement, but need feedback. Please take a look at these and let me know what you think. How could we change the messages to be even more descriptive?

Sadly, we can't do a whole lot about the deep recursive stack traces. But at least your code should end up at the top now when it fails. :-)

Check it out, let me know what you think!

-Chris

Edit: Forgot to mention, we also updated the Silverlight projects to Silverlight 3.

"Second, we're taking a first cut at fixing our horrendous exception messages."

Awesome, Fantastic, Rock on!!!   :-)   The BuildFailedException has come to be my nemesis.  I'll take a look at that hopefully in the near future.

Thanks!

Regarding Unity v2;

What happened to the CloneForNewBuild method on the IBuilderContext?

Alternatively, how to start a building process inside a building pipeline? This is something I heavily use in some Unity extensions.

Thanks.

Did you fix the bug that ResolveAll() does not return open generics?

I configuring container programmaticaly, but run into the same issue as described here:

http://unity.codeplex.com/WorkItem/View.aspx?WorkItemId=3392

http://unity.codeplex.com/Thread/View.aspx?ThreadId=40897

I use quick fix in my project:

public override IEnumerable<object> ResolveAll(Type t)
{
     List<string> names = new List<string>(registeredNames.GetKeys(t));

     if (t.IsGenericType)
     {
          Type tdef = t.GetGenericTypeDefinition();
          names.AddRange(registeredNames.GetKeys(tdef));
     }

     foreach (string name in names)
     {
          yield return Resolve(t, name);
     }
 }

This works just fine, but it does not preserve the order types was registered, but existing test fixtures relies on this order, so fixtures I've added are a little bit odd (they guess new order and will fail if fix will be more consistent).

Ordering of objects returned by ResolveAll() is not important for me at all. I was surprised to found that it is ordered. It seems this ordering is not documented anywhere. When I looked at tests I wondered why they use order sensitive collection assertion, and then found in code that objects returned in the same order as they was registered. I supposed that this is for some reason if Unity cares about it, but open generics resolving is much important for me and actually I already use array resolving with open generics via fix I posted.