Does anyone use ObjectBuilder2 standalone?

Nov 10, 2008 at 4:55 PM
When we originally built Unity, ObjectBuilder2 was kept in a separate assembly because we wanted to allow previous users of OB to continue doing so. However, I've heard nothing since about any use of ObjectBuilder outside of the Unity container.

As such, to simplify deployment I'm seriously considering merging the two assemblies into one in a future version. Would this cause any heartburn for anybody?

Nov 13, 2008 at 4:59 PM
I don't use Object Builder alone anymore, but I did use it directly from the time it made its appearence in 2.0 until Unity came along.  That said, I have no objections to the assemblies being combined.
Dec 10, 2008 at 7:42 PM
I've never used OB directly and I would have no objections to merging the assemblies.
Jan 28, 2009 at 7:34 AM
Dear ctavares,

Is it possible to drop ObjectBuilder2 project if we don't use ObjectBuilder?

Jan 28, 2009 at 4:57 PM
Please define "drop".

You still need the assembly if you use Unity, as the container relies on the code in OB2. You may (or may not) need an assembly reference depending on what you're doing.

Mar 24, 2009 at 9:52 AM
I'm planning to use it as a standalone... I actually need a configurable object factory, not a ioc nor a di framework.

Is it still possible?

Actually I could not undestand which object builder I've to use: WCFS (that we use) use OB1, codeplex provide a OB2 but as I could understand unity use a lightly modified OB2 version.

Since, in different context, I will also need a IOC system I'm plan to use Unity, so I'd prefer to use the Unity OB2 version for consistency.

Can you help me to choose a version?

Mar 24, 2009 at 2:14 PM
The Unity container basically is a configurable object factory.  If for some reason you don't want the overhead of the default DI behavior, you could just remove all the extensions and register your own to do whatever you're looking to do.
Mar 24, 2009 at 4:50 PM

The OB2 in the codeplex is a direct evolution of the original OB1 code. The goals there was to be more general purpose and correct some issues that the original authors felt were done incorrectly in OB1. As far as I know, they now consider that work complete.

The OB2 in Unity is significantly modified. We started from the Codeplex OB2 code, but then took a hacksaw to it, primarily in the pursuit of performance. And we succeeded in that goal, and in the process fixed some issues that *I* felt were done incorrectly in OB1. Going forward, the plan is to continue working on the underlying "OB" core, but it won't have a separate existing from Unity anymore. The goal here is to simplify the internals of the container, both for easier extensions and to (hopefully) pick up more performance.

OB1 is an official p&p release. OB2 codeplex is a community project. OB2 Unity is a p&p release, but it's going away in Unity V2. Does that help? (Probably not).

If you're planning to use Unity anyway going forward, you're probably best off writing against the Unity version of OB, but I'd recommend what Derek suggested - do it as container extensions. You'll need to build something like a container anyway to use OB, so might as well avoid reinventing the wheel.

Mar 25, 2009 at 8:19 AM
Thank for your replies! :-D

I've studied a bit the Unity 1.2 documentation and I've understood that it's definitely what we need for IOC.
But, actually there are components we are writing where dependencies should be inferred by coding conventions, lightening the (yet complex) configuration.

As far as I could understand, being Unity a IOC configurable container, it privilege configuration over conventions.

So what we actually need, is a configurable object factory, but we need it would read OUR configuration (which yet have an XSD and the so) and use some "coding conventions" to infer some of its creational behaviours.

Since Unity has it's own configuration, I'm not sure about it's usage for such projects.

All the documentation I've found explain how to use Unity for IOC or DI, but I could not find such a scenario.

Am I missing something?

Mar 26, 2009 at 9:40 PM
The Unity internals documentation is sadly slipping down the priority stack, but Unity is definitely capable of being reconfigured to support what you want to do. You could use a separate configuration reader to read your file and apply it to the container (just use the existing API), and you can also customize on a per type or globally how constructors and properties are chosen and resolved.

Mar 31, 2009 at 9:31 AM
Ok.. I've finally choose this way.

Can you point me to some code, sample or documentation about customizing the configuration reader?
Another thing: can I've have different container's instances?


On Thu, Mar 26, 2009 at 11:40 PM, ctavares <> wrote:

From: ctavares

The Unity internals documentation is sadly slipping down the priority stack, but Unity is definitely capable of being reconfigured to support what you want to do. You could use a separate configuration reader to read your file and apply it to the container (just use the existing API), and you can also customize on a per type or globally how constructors and properties are chosen and resolved.

Read the full discussion online.

To add a post to this discussion, reply to this email (

To start a new discussion for this project, email

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at

Apr 2, 2009 at 12:28 AM
What do you want to do? The configuration stuff we ship calls the existing public API. There are no configuration back doors, and nothing that can only be done by config. So really, what you need to do is decide what your configuration looks like, then in whatever code you use to read it, call the appropriate Unity API functions. Without more details on what you're trying to do it's hard to provide more information.

Apr 2, 2009 at 8:05 AM
Sorry, you are right, I was too vague...

I need to write a factory of complex, composite, generic objects.
The configuration is something like this:
<Handler id="RoutingHandler1" type="RoutingHandler" firstClosureType="Interface1" secondClosureType="Interface2">
     <Param Name="thirdClosureType" Value="ConcreteClass1"/>
     <Param Name="forthClosureType" Value="ConcreteClass2"/>
     <Param Name="ConcreteHandler"  Value="StrategyBasedHander1">
<Handler id="StrategyBasedHander1" type="StrategyBasedHandler" firstClosureType="ConcreteClass1" secondClosureType="ConcreteClass2">
     <Strategy target="rule1" type="AndStrategy">
        <Strategy type="OrStrategy">
            <Strategy type="Strategy1">
            <Strategy type="Strategy2">
<Strategy type="Strategy3">
     <Strategy target="rule2" type="Strategy4">
As you can see, building the Handler with id "RoutingHandler1" is a quite complex operation.
But, understanding how to configure this piece of software is a complex work by itself, so we decides to simplify the configuration scheme, to reduce at least error due to the .config fill.

To build the factory, we firstly decided to use p&p object builder. Than we knew that there is such a forest: OB1, OB2 and Unity's OB2.

I know it's a quite complex and custom scenario, but I think that an OB (without any IOC logic, just a factory) would be useful by itself.
At least, it would be useful for us!

That said, unsupported code would be a problem so we could move to Unity, even if we already use WCFS (and so OB1) and even if Unity is for IOC or DI, not actually a simple factory...


Apr 2, 2009 at 1:53 PM

    I don't use external config files for my DI/IoC setup, but the configuration example you've set forth appears to be more complex than what it seems to actually be accomplishing.  From what I can deduce, all you are doing is configuring an object with optional parameters and other composed types.  This is exactly what a DI container does for you.  My suggestion to you would be to do a spike on configuring your object using Unity's configuration before setting out to write your own.  If you find some limitation through that exercise, you will at least have done your due dilliengence on behalf of your company and can proceed from there.  The Enterprise Library installation has a section under "The Unity Application Block" entitled "Entering Configuration Information" that should get you started.

Apr 2, 2009 at 3:57 PM
The configuration I have provided is specular to the conceptual model it will configure.

Let me say that the number of Handlers that a real configuration will contain would be among a handred.
Some Handler has a peculiar implementation written in its code, but more often we will use a composition of well defined Strategies (composed by AndStrategy and OrStrategy, which actually are strategy by themself)

The tree of strategy for a single rule (it would require an essay to explain what such rules are) could be 5 level deep: (X and ((Y or Z) and (K and (...)))

Defining which strategy a single rule must have is a difficult intellectual work. But since such strategies could change in time we need that such configuration reflect
the way of thinking of who will configure (and reconfigure) the application.

The problem here is not IOC or DI. It's to build the Handlers (which may be generic types), some of which require a StrategySet (which IS a generic type) which contain a set of Strategy (some of which are generic types closed on the same types the StrategySet is). Some Strategy (as AndStrategy and OrStragety) delegate some of its work to other Strategy.

The complexity of what this configuration accoplish is by far highter than the configuration handling or the IOC itself.

But I can't use the Unity configuration as it is, becouse it would require a lot of headache to people which are not thinking in term of IOC, but in term of Handlers, StrategySet and Strategy...

That said I'm going to read "The Unity Application Block" section (but let me say that I've yet read the documentation provided in the codeplex Unity's download page).