Category Archives: ObjectBuilder

Circular Dependency in Unity

I have been toying around with an idea of replacing the ObjectBuilder in the WCSF with a proper dependency injector. The Unity seemed like the obvious choice (someone even tried porting WCSF to Unity) so I have been reading Dependency Injection with Unity.

During my research I have stumbled upon the ugly side of the Unity: It can’t detect circular dependencies. I though that it is only true in some old version, it would be hell trying to find the circular dependency only with StackOverflowException so I tested it out. After all “One good test is worth a thousand expert opinions”:

public interface IA {}
public interface IB {}

public class A : IA
  public A(IB ib) {}

public class B : IB
  public B(IA ia) {}

public void UnityContainer()
  using (var container = new UnityContainer())
    container.RegisterType<IA, A>();
    container.RegisterType<IB, B>();

It crashed, hard. The test didn’t pass, nor fail. I just got

—— Run test started ——
The active Test Run was aborted because the execution process exited unexpectedly. To investigate further, enable local crash dumps either at the machine level or for process vstest.executionengine.x86.exe. Go to more details:
========== Run test finished: 0 run (0:00:05,2708735) ==========

Unity_CircularDependency_StackOverflowExceptionDuring debugging the test, I got the dreaded StackOverflowException, so there it is: No detection of circular dependencies in the Unity and that is the reason why I won’t be using it. There are other fishes in the barrel.

I have tried Ninject and Castle Windsor, thankfully, both detect circular dependencies and throw exceptions with meaningful messages. Ninject has this error message:

Ninject.ActivationException: Error activating IA using binding from IA to A
A cyclical dependency was detected between the constructors of two services.
Activation path:
3) Injection of dependency IA into parameter ia of constructor of type B
2) Injection of dependency IB into parameter ib of constructor of type A
1) Request for IA

1) Ensure that you have not declared a dependency for IA on any implementations of the service.
2) Consider combining the services into a single one to remove the cycle.
3) Use property injection instead of constructor injection, and implement IInitializable
if you need initialization logic to be run after property values have been injected.

While Castle exception has this message:

Castle.MicroKernel.CircularDependencyException: Dependency cycle has been detected when trying to resolve component ‘UnityTest.A’.
The resolution tree that resulted in the cycle is the following:
Component ‘UnityTest.A’ resolved as dependency of
component ‘UnityTest.B’ resolved as dependency of
component ‘UnityTest.A’ which is the root component being resolved.

I am not impressed with the simplicity of the Castle nor with documentation of the Ninject, but I don’t want a nightmare of circular dependencies without meaningful error message in my project.

Builders in WCSF

Expect more details about mini-DI in WCSF. Be sure to read previous posts before this one.

WCSF has a two builders (i.e. builders that instantiate the requested objects), they are identical objects (and use identical type and service mappings), but have one crucial difference – singleton policy:

  • ApplicationBuilder – Builder used by the modules and thus in Module Initializers (MI). Its singleton policy is such, that created singletons are stored in the ILocatior. When MI adds a service to the module (e.g. using a container.ServicesNew<SomeService,ISomeService>()), the application builder is used and real singleton service is created. The service is available to all objects in the module and all child modules (unless they overwrite service mapping).
  • PageBuilder – Used by the pages and web controls. WCSF has a lot of slightly tailored WebControls in Microsoft.Practices.CompositeWeb.Web.UI that are subclasses from System.Web.UI, so with WCSF you use the Microsoft.Practices.CompositeWeb.Web.UI.Page instead of System.Web.UI.Page. The singleton policy is such that objects created by this builder are never added to the ILocator thus are never singletons.

Why is there a PageBuilder? The reason is simple, the PageBuilder is used only by the WCSF WebControls to build up the properties of the WebControls. The WCSF WebControls themselves are not instantiated by the ObjectBuilder, but by ASP.NET. The ObjectBuilder comes into a play using the a code in the event methods of the WCSF WebControls (that is the reason why they are there). The WCSF is using PageBuilder to populate the properties of a page using ObjectBuilder, e.g. in OnPreInit method of Page object, OnInit method of MasterPage and so on.

The WebControls themselves are never singletons thus the singleton policy of the PageBuilder and ApplicationBuilder differ.

Crucial difference

Just because PageBuilder doesn’t store singletons doesn’t mean that it always created a new service instance for services. Thanks to default order of the strategies and common ILocator, if it finds a [ServiceDependency], it will locate the service in the ILocator (populated in ModuleInitializer) and uses already existing instance!

The difference in singleton policy is only if created instance is stored in ILocator or not. If there already is an instance, the WCSF will use it.

Basically they tried to work around the problem of how to build up a page we haven’t instantiated. They build it up (=fill public [CreateNew]/[ServiceDependency] properties) in the OnPreInit/OnInit methods of WebControls.

How to use

You use PageBuilder automatically when you use WCSF WebControl. If you really need to use it, call static method WebClientApplication.BuildItemWithCurrentContext(objectToBeBuild).

The ApplicationBuilder property is in Global.asax (the page is derived from the WebClientApplication). To use application builder, follow the code of the BuildItemWithCurrentContext. Basically you need

IModuleContainerLocatorService – WCSF service to locate module from the URL of the page. Use the current URL and get a CompositionContainer of a module.

From CompositionContainer get ILocator and call

webApp.ApplicationBuilder<TypeToBeBuild>(locator, idToBuild, nullOrExistingObject);

For more info, just dive into the source (or not.. I would rather not).

ObjectBuilder in WCSF

I have described how does the ObjectBuilder work in the previous post. The reason why I even started to investigate the internals of a dead project is because of the WCSF – another dead project.

Since OB is a framework for building DI, the WCSF has created its own simple DI with two ways to build up objects – either as singletons or new objects. The depending objects can be inserted either through constructor or through properties.

The WCSF has its own builder of objects – the WCSFBuilder class derived from WCSFBuilderBase. It should be noted that when you diff the WCSFBuilderBase from the WCSF and BuilderBase from OB, they are quite similar and there was no reason to reimplamenetcopy&edit the base builder class.

The gist of WCSF are four strategies:


Policies.SetDefault<ICreationPolicy>(new DefaultCreationPolicy());
Policies.SetDefault<IBuildPlanPolicy>(new BuildPlanPolicy());

private static IPlanBuilderPolicy CreatePlanBuilder()
  BuilderStrategyChain chain = new BuilderStrategyChain();
  chain.Add(new CallConstructorStrategy());
  chain.Add(new SetPropertiesStrategy());
  chain.Add(new CallMethodsStrategy());

  PolicyList policies = new PolicyList();
  policies.SetDefault<IConstructorChooserPolicy>(new AttributeBasedConstructorChooser());
  policies.SetDefault<IPropertyChooserPolicy>(new AttributeBasedPropertyChooser());
  policies.SetDefault<IMethodChooserPolicy>(new AttributeBasedMethodChooser());

  return new DynamicMethodPlanBuilderPolicy(chain, policies);

As you can see, the OB has four chained strategies that are chained.



This is strategy that preprocess the buildup request before passing it to the rest of chain, it doesn’t actually build the object. Its task is to change requested type to the type we actually to build up, in most cases it maps interfaces to concrete classes, e.g. ITimeService to NetworkTimeProtocolService. The precise mapping is defined by ITypeMappingPolicy.


This strategy is quite simple:

  • If locator contains an instance of requested object with id&type -> Return instance
  • Otherwise build up the object using rest of chain, insert it to locator and return it.

The startegy checks and respects ISingletonPolicy of builder. If the policy says no to singletons, new instance is not injected into locator.


This is a candidate for The Daily WTF. When I go through all the stuff and dependency, it seems to create a specialmethod using ILGenerator just for creation. We actually have things like il.Emit(OpCodes.Ldarg_2);. Generating assembler at runtime… In 2008.

This strategy uses DynamicMethodPlanBuilderPolicy that basically for each type creates a dynamically created method (using ILGenerator and opcodes) for building an object of the type. The strategy then calls the method to create the object and passes the created object to the next link of the chain.

The interesting part is DynamicMethodPlanBuilderPolicy.CreatePlan – the method returns dynamic method “BuildUp_” + typeToBuild that will be executed on typeToBuild class.

The code of method is generated sequentially by the chain from CreatePlanBuilder from code snippet above:

// Code used to create a method that will build up the typeToBuild in the DynamicMethodPlanBuilderPolicy used by BuildPlanStrategy
ILGenerator il = buildMethod.GetILGenerator();
// In this chain is the CallConstructorStrategy, SetPropertiesStrategy and CallMethodsStrategy
context.HeadOfChain.BuildUp(context, typeToBuild, il, idToBuild);

The CallConstructorStrategy check if existing object is null, if not, it builds up parameters of constructor and calls it.

  • The SetPropertiesStrategy builds up and sets objects for all marked properites ([CreateNew]/[ServiceDependency]).
  • The CallMethodsStrategy – It will call all methods of the object that have the [InjectionMethod] attribute with build up parameters.

Aaaargh! Is there any reason to do this instead of three link of build starategy chain, where

  • first link creates an instance using constructor and passes it to the second one
  • second link builds up and assigns instances to the [CreateNew]/[ServiceDependency] properties of the object
  • third calls all [InjectionMethod] methods of the existing object.

UPDATE: Somebody probably thought so too, because there are three unused strategies that do exactly that: ConstructorReflectionStrategy, PropertyReflectionStrategy and MethodReflectionStrategy.

Once the method creates the existing object, is is passed to the last strategy:


Post initialization task, this strategy checks if passed existing object is an instance of IBuilderAware and if it is, the OB will call OnBuiltUp method of the existing object.

I think this strategy is used only in tests of WCSF, e.g. if WCSF did build up a WCSF UserControl.


ObjectBuilder is a C# dependency injection framework, more precisely it is a framework for building a dependency injectors. There were two versions, the Object Builder 2 was later integrated into Unity Application Block.

The earlier versions is used by Web Client Software Factory (WCSF), the library for building web applications in WebForms. It is tool we are using for our internal system.

The first thing I notices about Object Builder is that it is woefully undocumented (official MSDN documentation), the source code is available, but no quick start or anything. I have googled a little and found very helpful post about how to actually use it to create objects. – sort of quick start tutorial.

Good, but not enough, I am trying to transfer out C# app from Web Site Project in Web Forms and WCSF to to MVC, but since WCSF auto-magically inserts all dependencies, I had to dive into source code of OB in order to understand it and later integrate it for MVC controller creation (I want to insert already existing services and other stuff into MVC controllers).

First, it is good to have an idea what functionality of ObjectBuilder do I have to replicate:

  • Services – Singletons that are alive during the whole life of web app. When constructor of object or property of object has a attribute [ServiceDependency], the OB will put there a singleton instance of some object.
  • New objects – whenever asked (through attribute [CreateNew]), the OB creates a new object.
  • There is also some registration of services and type mappings, but I am only interested in how to create a new object / get service just like the WCSF would.

Since the OB is not a dependency injection framework, but rather framework for building DI, it has only very simple DI framework – the one that can either create a new object or use singleton singleton instance.

The WCSF can use DI in two ways, either through constructor or by filling proprties (see official documentation):

public class MyClass {
  public MyClass(
    [CreateNew] IStoreInventory storeInventory,
    [ServiceDependency] ITimeService timeService)
    // ... object initialization
  public IMyService MyService {get;set;}

Core concepts of the ObjectBuilder:

  • IBuilder – The builder that builds up or tears own the objects. The BuilderBase class is easy to understand. You can create a object like this
builder.BuildUp<MyClass>(locator, idToBuild, existing)
// In reality all parameters can be null when not used

The builder has a chain of building strategies (the various ways to create an object).

  • IBuilderStrategy – Strategy how will the objects be build.

The strategies can be varied, e.g. singleton strategy can look through locator and if there already is an object, return it; if the object is not in locator, create it, add to locator and return it. Or the the object can be build by some factory method.

  • IBuilderPolicy – Policy tailoring concrete implementations of IBuilderStartegy, e.g. IMethodPolicy can tailor which method will be called by MethodExecutionStrategy.
  • IBuilderContext – context used for one request to build up an object. It consists from locator, chain of building strategies and list of policies. It basically only holds tailored data passed to the chain of strategies of IBuilder.
  • ILocator – Basically a dictionary of id-object, it is used mostly for singletons, so when someone asks for an object with specified id, the OB will use locator to locate it.

When we request an object from IBuilder, it

  1. takes passed paramaters,
  2. creates a new IBuilderContext from passed parameters and other internal data (strategies, policies)
  3. IBuilder asks the head of builder strategy chain to build up an object.
  4. The IBuilderStartegy will look at the IBuilderContext and other data and determines if it can build up an object. If it can, it returns an object. If it can’t, it asks the next strategy in builder chain to try to build up the object. Note that each link of chain must call previous link.
  5. The base implementation BuilderStartegy of IBuilderStartegy will return the existing object (the one passed as parameter into IBuilder.BuildUp), if all strategies in chain fail.

This is rather high level description of OB, concrete example how to set it up, look at the David Hayden blog.