Latest checkin just posted

Jul 13, 2009 at 7:59 PM
Edited Jul 13, 2009 at 10:46 PM

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.

 

Jul 22, 2009 at 8:59 PM

Hi,

I see that the code does not support .NET 2.0 anymore? Is this part of the design?

The assemblies are also not strongly signed?

 

Thanks.

D

Jul 22, 2009 at 11:59 PM

"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!

Jul 24, 2009 at 6:00 AM

Yes, we're moving the framework requirement for Unity 2.0 up to .NET 3.5 SP1. There's lots of great stuff in there (like lambdas & linq) that we'd like to take advantage of it. And with .NET 4.0 on the horizon, it turns out that if we want Unity to run (even as a binary) on 4.0 projects, we need to update some of our code to use a method that only exists in .NET 3.5.

The source code does not have a key supplied, that is correct. We use a command line switch to turn signing on and off. We can't ship source with strong names anyway; that'd require us to ship a Microsoft private key, which defeats the purpose of signing in the first place. When we do an actual binary release, those assemblies will be strong named and authenticode signed as usual.

 

Jul 27, 2009 at 5:13 PM

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.

 

Jul 28, 2009 at 5:49 PM

Well, we realized that every time we called CloneForNewBuild, we were doing the exact same thing. Everywhere. So we ditched the "CloneForNewBuild(); clone.Strategies.Execute(clone);" dance in favor of the NewBuildUp method (and associated extension methods), which do the same thing in one step instead of three.

If you need more specific control over the context, let me know and we'll get that capability back in there.

 

Aug 19, 2009 at 6:49 AM

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).

Aug 24, 2009 at 7:43 PM

That is on the list of things to fix. I have no idea how to preserve the ordering in the presence of both generic and non-generic types within the current implementation. How important is it to you other than that the current tests depend on it?

 

Aug 25, 2009 at 8:56 AM

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.

Oct 26, 2009 at 11:21 AM

Hi Chris,

Is there a CSL adapter for Unity version 2.0?

The problems when using virtual method interception are fixed? (for example: by having virtual methods in parent classes, sometimes the methods of the subclasses lose interception)

I have a project in that I use Unity 1.2 + CSL. I workaround this problem by keep all base classes clean of any "virtual" code. But it's possible that in the future doing this makes imposible.

Thanks!