Converting the Composite Web Application Block to Unity – Using the UnityCompositionContainer

This is the sixth post in a series. The other post include:

If you want background, go read the earlier posts.

Based upon feedback, I am making the source code available at CWAB and Unity.

For those who have been following along, you all know I am making this up as I go. So, I am asking that you be patient with me as we figure this out together. This article (in particular) may have a few false starts, and "ooops" moments.  We are replacing something that was not meant to be pluggable, and all of the refactoring work that has been done up to this point may not be enough.

Reminder:  This is a proof of concept.  The version of CWAB I am creating here is not a supported product or guidance from patterns & practices.  If you really want Unity support in WCSF, please go to the Issue Tracker on the WCSF Community Site and vote for the work item to get Unity support for WCSF.

At the end of the last post I planned on trying to actually use the UnityCompositionContainer, and then nuke the old CompositionContainer.

Let's get started by replacing any calls that creates a CompositionContainer with code that creates a UnityCompositionContainer.  There is ONE spot, in WebClientApplication.  Simple. Change, recompile, re-run unit tests, and we are green.

If it really was that simple, we should be able to remove the CompositionContainer class (and its test fixture) from the solution, and not have any challenges.  Let's try that.

We fail to compile.  Our TestableRootCompositionContainer is part of the problem. MockContainer in ManagedObjectCollectionFixture is the rest of it.

If we derive TestableRootCompositionContainer from UnityContainer, and remove everything from the class (as a temporary measure), we go from two to 27 build errors. 

<timewarp duration="an or two"/>

Not good.  But not too bad, considering what comes next.  After fixing these build errors, I got on a roll, and did the following:

  • Removed references to the old ObjectBuilder.dll in both unit test and system projects
  • Removed the BuilderStrategies folder in both unit test and system projects
  • Removed the Collections folder in both unit test and system projects
  • Removed the ObjectBuilder folder in both unit test and system projects
  • Removed the ProviderDependencyAttribute and its fixture
  • Removed StateDependencyAttribute and its fixture
  • Removed OptionalDependencyAttribute and its fixture
  • Removed ServiceDependencyAttribute and its fixture
  • Removed all references to the old ObjectBuilder namespace
  • Replaced any [CreateNew] attributes with the Unity [Dependency] attribute
  • Hacked on WebClientApplication
  • Removed the Services collection.  Replaced calls to container.Services.Add with container.RegisterType.  If needed added a call to container.Resolve, when the Services.Add call was supposed to return an object.

Ok, things are compiling again.  Finally.  But there are a few failing unit tests, about 20 or so...  Let's fix those.

<type... type.... swear.... type />

Getting those test to pass was fairly simple.  All of them required a little bit of container setup that was different than before.  This was not a big deal.

There is one major change I did make in the process, and a related renaming.  First, the renaming, Page became InjectablePage; MasterPage became InjectableMasterPage, and guess what UserControl became? Excactly, InjectableUserControl.  These are better descriptions and will remove the confusion I have dealt with on the forums where people use the wrong Page base class.  The other change is that, previously CompositionContainer had two Builders: one for things like services that stayed around, and another for Pages and transient items like presenters.  We no longer need two builders, and can get containers and lifetime managers to handle the differences.  The approach I took for simplicity is to have each page create a container that is a child of the correct Module container, use this for doing injection on the page, and then nuking the container on Page.Dispose.  This is quick and dirty, and it works, but I may revisit it later.

Now, since Unity 1.1 just shipped, it is time to upgrade.  I replaced the binaries and...

Everything still passes.

I think that is enough for today.

As a quick check, I just looked at the solution statistics for the original version of CWAB and the current solution.  CWAB went from 26KLOC (pre-article one) to 14KLOC, both numbers including unit tests.  And I bet that there is more to be cut out and cleaned up.  Having a purpose built, re-usable component for DI helped a lot here.  For this edition, windiff will probably be the best bet for following all the types of changes I made.  This one took a while and impacted a lot of code.

Next, I am going to review unit tests, run code coverage, determine if there are gaps in test coverage after all the hacking.  After that, it will be porting one of the quickstarts over to the new version of CWAB.  After that, the RI, at which point I will be sure that the updated version works well enough to be a good proof of concept.

Comments (8)

  1. BennyXNO says:

    I liked your naming proposal. InjectableXXXX

    Good names are seldom to see.

  2. Phil Bolduc says:

    CWAB went from 26KLOC (pre-article one) to 14KLOC. If I did my math correctly, that is 46% less lines of code.  That is awesome.

  3. says:

    Any more progress on this? I just ran across your article series and am drooling for a working version.

  4. mpuleio says:

    RE: BennyXNO,

    Thanks, I never did get a chance to fix that before WCSF shipped.  I think it is confusing to a lot of people to have the same type name in different namespaces (Page in both System.Web.UI and MS.practices….wherever).

    RE Phil,

    Just wait until you see what might happen after incorporating some ideas Chris and I just played with.

    RE mousedoc,

    Soon.  Life has been crazy recently, and I have not made much progress.  But I will get back to this soon.

  5. Preguntas como por que se colocan las propiedades en la interfase de la vista, que debe de ir en el Application

  6. Managed Extensibility Framework (MEF) used to make a Composite Web ASP.NET Forms Application

  7. You’ve been kicked (a good thing) – Trackback from

Skip to main content