Espresso Fueled Agile Development : .NET

Where is WCSF headed?

mpuleio — Wed, 03 Dec 2008 21:24:19 GMT

Blaine & I have been getting a lot of emails, messages, comments, etc about WCSF. There are a lot of people interested in a public statement from patterns & practices about the roadmap for WCSF and future support of WCSF, in addition to the "normal" feature requests.

Well, we have some good news: Blaine has publicly released the WCSF roadmap in his blog as Roadmap for WCSF.

Basically, right now, we are asking for feedback from the community. Let Blaine and/or I know what you want via our blogs, email, or the WCSF CodePlex site at www.codeplex.com/websf. You can also create work items/ issues on the WCSF CodePlex site and have people vote on them (http://www.codeplex.com/websf/WorkItem/List.aspx).

Thanks in advance for the feedback...

[Edit: I created a specific thread on the CodePlex discussions board to facilitate feedback: http://www.codeplex.com/websf/Thread/View.aspx?ThreadId=41403). Enjoy]

Composite Application Guidance for WPF Shipped!

mpuleio — Thu, 31 Jul 2008 20:26:13 GMT

A while back, I was Dev Lead on the Smart Client Software Factory (SCSF) when we added the ability to host WPF controls in a Composite Application Block (CAB) application. Since then, the thinking in the WPF space has changed a bit, and p&p decided that offering guidance on full WPF applications was a good idea. Blaine, Francis, Bob, and Glenn have worked with a great team to create guidance for building composite applications using WPF. This guidance was started from a clean slate, as there are enough differences between Windows Forms and WPF (as we learned doing SCSF) to cause challenges. The result is the Composite Application Guidance for WPF June 2008, which recently shipped (formerly code-named Prism). This guidance is simple, easy to consume, can be used piecemeal, and should not have the steep learning curve that CAB and SCSF have. You can learn more at the Prism CodePlex Community Site, or at any of the places below.

Check out Francis's post, SHIPPED!!! Composite Application Guidance for WPF June 2008, for details and where to get it.

Or take a look at Glenn's post on the subject: Composite Application Guidance is Live

And here are a few other posts about what they have been up to, by person in chronological order:

From Francis:

From Blaine:

From Glenn:

I know I am looking forward to using this guidance when I get a chance to work with WPF more seriously.

Enjoy.

Proof of Concept: a simple DI solution for ASP.NET WebForms

mpuleio — Thu, 17 Jul 2008 23:32:22 GMT

Chris Tavares and I were chatting yesterday morning about an idea Chris had: building a simple, reusable Http Module that gives folks DI scoped to the Application, Session, and Request. Yesterday afternoon, during the p&p Dev team's weekly "Code Kata" we threw together a spike/proof of concept in a couple of hours. "Code Kata" is a three hour block of time that the p&p Dev team uses for a number of things:

cross-project pollination of ideas, things that work, things that don't work across project teams
investigating new and emerging technologies that p&p may work with in the future
investigating new and emerging platforms to determine if p&p may want to provide guidance in the future
play with new shiny bits :-)

There are no unit tests, just simple acceptance tests written as a really simple web site. If the site works and shows the right text, the test passes. We started with a list of requirements (scaled to just the application level) on the whiteboard that looked sort of like this (which I am creating from memory):

Create a DI container for the application
Create a way to get to the container ( we choose an extension method on the Application class)
Allow a way to configure the container
Allow DI to work for pages
Allow DI to work for user controls
Allow DI to work for master pages
Allow DI to work for ASMX web services
Allow the above functionality in a simple and self contained way

So, we created a simple Web Site Application and a DLL to hold the custom HttpModule. We created a simple web page that needed a property injected into it. We then wrote the code to make my "test" page work properly. First we wrote an extension method for HttpApplication. After a short bit it changed to one for HttpApplicationState:

using System.Web;
using Microsoft.Practices.Unity;

namespace UnityForTheWebLib
{
    public static class HttpApplicationStateExtensions
    {
        private const string GlobalContainerKey = "Your global Unity container";

        public static IUnityContainer GetContainer(this HttpApplicationState application)
        {
            application.Lock();
            try
            {
                IUnityContainer container = application[GlobalContainerKey] as IUnityContainer;
                if(container == null)
                {
                    container = new UnityContainer();
                    application[GlobalContainerKey] = container;
                }
                return container;
            }
            finally
            {
                application.UnLock();
            }
        }
    }
}

Basically, we have lazy initialization of the container and a mechanism to stuff it into the application state. And then the initial HttpModule that only does injection on a Page:

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using Microsoft.Practices.Unity;

namespace UnityForTheWebLib
{
    public class UnityHttpModule : IHttpModule
    {
        #region IHttpModule Members

        ///<summary>
        ///Initializes a module and prepares it to handle requests.
        ///</summary>
        ///
        ///<param name="context">An <see cref="T:System.Web.HttpApplication"></see> that provides access to the methods, properties, and events common to all application objects within an ASP.NET application </param>
        public void Init(HttpApplication context)
        {
            context.PreRequestHandlerExecute += OnPreRequestHandlerExecute;
        }

        ///<summary>
        ///Disposes of the resources (other than memory) used by the module that implements <see cref="T:System.Web.IHttpModule"></see>.
        ///</summary>
        ///
        public void Dispose()
        {
        }

        #endregion

        private void OnPreRequestHandlerExecute(object sender, EventArgs e)
        {
            IHttpHandler handler = HttpContext.Current.Handler;
            HttpContext.Current.Application.GetContainer().BuildUp(handler.GetType(), handler);
        }
    }
}

This is a very simple module that calls BuildUp on the page.

At this point we added another test, and implemented it. After a few iterations of this we ended up with tests for injection into a User Control and a Master Page, an interface that needed to be configured on the container. The final implementation of the Http Module looks like this

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using Microsoft.Practices.Unity;

namespace UnityForTheWebLib
{
    public class UnityHttpModule : IHttpModule
    {
        #region IHttpModule Members

        ///<summary>
        ///Initializes a module and prepares it to handle requests.
        ///</summary>
        ///
        ///<param name="context">An <see cref="T:System.Web.HttpApplication"></see> that provides access to the methods, properties, and events common to all application objects within an ASP.NET application </param>
        public void Init(HttpApplication context)
        {
            context.PreRequestHandlerExecute += OnPreRequestHandlerExecute;
        }

        ///<summary>
        ///Disposes of the resources (other than memory) used by the module that implements <see cref="T:System.Web.IHttpModule"></see>.
        ///</summary>
        ///
        public void Dispose()
        {
        }

        #endregion

        private void OnPreRequestHandlerExecute(object sender, EventArgs e)
        {
            IHttpHandler handler = HttpContext.Current.Handler;
            HttpContext.Current.Application.GetContainer().BuildUp(handler.GetType(), handler);

            // User Controls are ready to be built up after the page initialization is complete
            Page page = HttpContext.Current.Handler as Page;
            if (page != null)
            {
                page.InitComplete += OnPageInitComplete;
            }
        }

        // Get the controls in the page's control tree excluding the page itself
        private IEnumerable<Control> GetControlTree(Control root)
        {
            foreach (Control child in root.Controls)
            {
                yield return child;
                foreach (Control c in GetControlTree(child))
                {
                    yield return c;
                }
            }
        }

        // Build up each control in the page's control tree
        private void OnPageInitComplete(object sender, EventArgs e)
        {
            Page page = (Page) sender;
            IUnityContainer container = HttpContext.Current.Application.GetContainer();
            foreach (Control c in GetControlTree(page))
            {
                container.BuildUp(c.GetType(), c);
            }
        }
    }
}

Configuration of the container can happen in the Global Application_Start handler like this:

using System;
using Microsoft.Practices.Unity;

namespace UnityForTheWebTestSite
{
    public class Global : System.Web.HttpApplication
    {

        protected void Application_Start(object sender, EventArgs e)
        {
            IUnityContainer c = Application.GetContainer();
            c.RegisterType<IControlData, ControlData1>();
        }
    }
}

So, from the initial requirements we have this:

~~Create a DI container for the application~~ Lazy initialization
~~Create a way to get to the container ( we choose an extension method on the Application class)~~ Extension Method
~~Allow a way to configure the container~~ Application Start
~~Allow DI to work for pages~~ Add the HttpModule and Attributes
~~Allow DI to work for user controls~~ Add the HttpModule and Attributes
~~Allow DI to work for master pages~~ Add the HttpModule and Attributes
Allow DI to work for ASMX web services
~~Allow the above functionality in a simple and self contained way~~ This is all in a single module

We met the last requirement (simple and self contained) since all we did to the web application was add a single line to the web config. That met the requirement.

The last area is one we met, but we are not happy with the solution. Basically, we need to do a bit more research and see if there is a way to get into the pipeline for an ASMX request early enough to do injection and not screw things up for the normal use case or the Ajax extensions. Until we get this figured out right, the solution is to have your Web Service constructor ask the container to do injection. This is an ugly hack and looks something like this:

using System.ComponentModel;
using System.Web;
using System.Web.Services;
using Microsoft.Practices.Unity;

namespace UnityForTheWebTestSite
{
    [WebService(Namespace = "http://tempuri.org/")]
    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    [ToolboxItem(false)]
    // To allow this Web Service to be called from script, using ASP.NET AJAX, uncomment the following line. 
    // [System.Web.Script.Services.ScriptService]
    public class MyWebService : System.Web.Services.WebService
    {
        public MyWebService()
        {
            HttpContext.Current.Application.GetContainer().BuildUp(this);
        }

        [Dependency]
        public IControlData Data
        {
            get;
            set;
        }

        [WebMethod]
        public string HelloWorld()
        {
            return "Hello World " + Data.GetText();
        }
    }
}

To add the ability to have a container at the Session level and the request level should be as simple as following the pattern for the extension method and the http handler above. (I will leave it as an exercise for the reader.) You could use the same container for everything, or have the Session container a child of the application container, and the request container a child of the session container. When and if we do a real implementation (as opposed to a proof of concept) we will figure out the best approach for most cases. When and if this happens, I will update my CWAB with Unity solution and dramatically simplify it. :-)

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

mpuleio — Wed, 21 May 2008 19:38:11 GMT

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.

Converting the Composite Web Application Block to Unity - Actually Adding Unity

mpuleio — Fri, 02 May 2008 02:44:34 GMT

This is the fifth 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.

First off, I have moved this little side project to source control, so I can avoid the re-work I had to do before I could write this part of the series.

Note to self :

NEVER work without a safety net. That means both unit tests and source control.

Ok. Now that that is out of the way....

Let's go add Unity to CWAB, via EDD (formerly TDD).

How can we do this? First, we need a test fixture. So, I added CompositionContainerFixture to the CompositeWeb.Tests project as an empty test fixture. And then I added the following very simple test as a starting point:

[TestMethod]
public void UnityCompositionContainerIsICompositionContainer()
{
    UnityCompositionContainer container = new UnityCompositionContainer();
    Assert.IsInstanceOfType(container, typeof(ICompositionContainer));
}

This will allow me to write enough code to create the UnityCompositionContainer class and ensure that it implements the right interface.

Making the test compile forces me to create a new UnityCompositionContainer class (I added it to the fixture as a nested class for the moment), and the test fails. No problem. I add the interface, implement it with methods that throw, and..... We are green again.

Next step, I copied the unit test RootContainerParentIsNull over, changed its name to NewUnityContainerParentIsNull, updated it to create a new UnityCompositionContainer, and compiled and ran the test. It passed, which is not idea;l, but I will leave it an move on, knowing it will be important later. For the next test, I copied ChildContainerHasParent changed its name to NewUnityContainerParentIsNull, updated it to create a new UnityCompositionContainer, and compiled and ran the test... Red. Just like we expected. To make this work, I could do a bit of throw away work, or I could add Unity. I feel like I can skip the simplest thing possible, because I know where I want to go.

However, first, I'm doing a check-in. I'll comment out the failing test, and sync up. Just a sec.

Ok, now To add Unity. I grabbed the binaries from MSDN, dropped them in my tree in the Lib folder and we are good to go. I added references in the CWAB projecct to Unity.DLL and ObjectBuilder2.DLL. This means we have two completely separate DI systems as part of out code, which is awful. However, it won't last too long.

Now, we can make that test pass. I added an IUnityContainer field to UnityCompositionContainer. I then implemented a constructor to initialize it. Then we needed to implement CreateChildContainer. For this, the simplest thing was to create a new constructor for UnityCompositionContainer which takes a parent container as the only parameter. After a little wire-up we end up with passing tests and this code:

private UnityCompositionContainer(UnityCompositionContainer parentContainer)
{
    Parent = parentContainer;
    wrappedContainer = parentContainer.wrappedContainer.CreateChildContainer();
}

public ICompositionContainer CreateChildContainer()
{
    UnityCompositionContainer child = new UnityCompositionContainer(this);
    return child;
}

Fairly simple. I will continue moving unit tests over, adapting them, and making them pass. If there are any interesting deviations from normal, or new tests added, I'll let you know.

That was actually fairly simple. I copied the tests one at a time, replaced the container used with the UnityCompositionContainer, compiled, ran the tests, watched them fail due to NotImplementedExceptions, and fixed them. Here's the test fixture:

[TestClass]
public class UnityCompositionContainerFixture
{
    [TestMethod]
    public void UnityCompositionContainerIsICompositionContainer()
    {
        UnityCompositionContainer container = new UnityCompositionContainer();
        Assert.IsInstanceOfType(container, typeof (ICompositionContainer));
    }

    [TestMethod]
    public void NewUnityContainerParentIsNull()
    {
        ICompositionContainer container = new UnityCompositionContainer();
        Assert.IsNull(container.Parent);
    }

    [TestMethod]
    public void ChildContainerHasParent()
    {
        ICompositionContainer parent = new UnityCompositionContainer();

        ICompositionContainer child = parent.CreateChildContainer();

        Assert.AreSame(parent, child.Parent);
    }

    [TestMethod]
    public void CanRegisterTypeMappingOnRootContainer()
    {
        UnityCompositionContainer root = new UnityCompositionContainer();

        root.RegisterType<IFoo, Foo>();

        IFoo resolvedIFoo = root.Resolve<IFoo>();

        Assert.AreEqual(typeof (Foo), resolvedIFoo.GetType());
    }

    [TestMethod]
    public void CanRegisterTypeMappingViaTypeObjects()
    {
        UnityCompositionContainer root = new UnityCompositionContainer();
        root.RegisterType(typeof (IFoo), typeof (Foo));

        IFoo resolvedIFoo = root.Resolve<IFoo>();

        Assert.AreEqual(typeof (Foo), resolvedIFoo.GetType());
    }

    [TestMethod]
    public void RequestingTypeMappingForUnmappedTypeReturnsRequestedType()
    {
        UnityCompositionContainer root = new UnityCompositionContainer();

        Foo resolvedFoo = root.Resolve<Foo>();

        Assert.AreEqual(typeof (Foo), resolvedFoo.GetType());
    }

    [TestMethod]
    [ExpectedException(typeof (ArgumentException))]
    public void TypeMappingsMustBeTypeCompatible()
    {
        UnityCompositionContainer root = new UnityCompositionContainer();
        root.RegisterType(typeof (IBar), typeof (Foo));
    }

    [TestMethod]
    public void CanRegisterMultipleTypeMappings()
    {
        UnityCompositionContainer root = new UnityCompositionContainer();

        root.RegisterType<IFoo, Foo>();
        root.RegisterType<IBar, Bar>();
        IBar b = root.Resolve<IBar>();
        IFoo f = root.Resolve<IFoo>();

        Assert.AreEqual(typeof (Bar), b.GetType());
        Assert.AreEqual(typeof (Foo), f.GetType());
    }

    [TestMethod]
    public void RequestingTypeMappingOnChildReadsFromParent()
    {
        UnityCompositionContainer parent = new UnityCompositionContainer();
        ICompositionContainer child = (ICompositionContainer) parent.CreateChildContainer();

        parent.RegisterType<IFoo, Foo>();

        Assert.AreEqual(typeof (Foo), child.Resolve<IFoo>().GetType());
    }

    [TestMethod]
    public void ChildContainersCanOverrideParentTypeMapping()
    {
        UnityCompositionContainer parent = new UnityCompositionContainer();
        ICompositionContainer child = (UnityCompositionContainer) parent.CreateChildContainer();

        parent.RegisterType<IFoo, Foo>();
        child.RegisterType<IFoo, Foo2>();

        Assert.AreEqual(typeof (Foo), parent.Resolve<IFoo>().GetType());
        Assert.AreEqual(typeof (Foo2), child.Resolve<IFoo>().GetType());
    }

    [TestMethod]
    public void CanCreateChildContainer()
    {
        ICompositionContainer container = new UnityCompositionContainer();

        ICompositionContainer child = container.CreateChildContainer();
        Assert.IsNotNull(child);
        Assert.AreNotSame(container, child);
    }

    [TestMethod]
    public void CanRegisterInstance()
    {
        UnityCompositionContainer root = new UnityCompositionContainer();
        root.RegisterInstance(typeof (string), "foo", "bar");
        string returned = (string) root.Resolve(typeof (string), "foo");
        Assert.AreEqual("bar", returned);
    }


    [TestMethod]
    public void CanRegisterInstanceViaGenericWithoutName()
    {
        ICompositionContainer root = new UnityCompositionContainer();
        Foo f1 = new Foo();
        root.RegisterInstance<Foo>(f1);
        Foo returnedFoo = (Foo) root.Resolve(typeof (Foo));
        Assert.AreEqual(f1, returnedFoo);
    }

    [TestMethod]
    public void CanRegisterInstanceViaGenericWithName()
    {
        ICompositionContainer root = new UnityCompositionContainer();
        Foo f1 = new Foo();
        root.RegisterInstance<Foo>("asdf", f1);
        Foo returnedFoo = (Foo) root.Resolve(typeof (Foo), "asdf");
        Assert.AreEqual(f1, returnedFoo);
    }


    [TestMethod]
    public void CanResolveViaGenericWithoutName()
    {
        ICompositionContainer root = new UnityCompositionContainer();
        Foo f1 = new Foo();
        root.RegisterInstance<Foo>(f1);
        Foo returnedFoo = root.Resolve<Foo>();
        Assert.AreEqual(f1, returnedFoo);
    }

    [TestMethod]
    public void CanResolveInstanceViaGenericWithName()
    {
        ICompositionContainer root = new UnityCompositionContainer();
        Foo f1 = new Foo();
        root.RegisterInstance<Foo>("asdf", f1);
        Foo returnedFoo = root.Resolve<Foo>("asdf");
        Assert.AreEqual(f1, returnedFoo);
    }

    [TestMethod]
    public void UnityCompositionContainerImplementsIDisposable()
    {
        UnityCompositionContainer disposableContainer = new UnityCompositionContainer();
        Assert.IsNotNull(disposableContainer as IDisposable);
    }

    // This test is commented out intentionally. The purpose of this test is to show 
    // that if you use the generic version of the RegisterTypeMapping method, if the
    // types aren't compatible it'll fail at compile time. 
    // 
    // This is exactly what happens. However that also means this file won't compile.
    // The test is left in as comments, if you wish to verify this then remove the comments,
    // watch the compile file, and then comment it out again.

    //[TestMethod]
    //public void GenericTypeMappingRegistrationEnforcesCompileTimeCompatibility()
    //{
    //    UnityCompositionContainer root = new UnityCompositionContainer();
    //    root.RegisterType<IBar, Foo>();
    //}
}

Notice, there are no tests for the Services collection. This is intentional. We will see if we can avoid implementing the methods at all.

And here is the code to make those tests pass:

public class UnityCompositionContainer : ICompositionContainer, IDisposable
{
    private ICompositionContainer parent = null;
    private IUnityContainer wrappedContainer;

    public UnityCompositionContainer()
    {
        wrappedContainer = new UnityContainer();
    }

    private UnityCompositionContainer(UnityCompositionContainer parentContainer)
    {
        Parent = parentContainer;
        wrappedContainer = parentContainer.wrappedContainer.CreateChildContainer();
    }

    public ICompositionContainer Parent
    {
        get { return parent; }
        set { parent = value; }
    }

    public IServiceCollection Services
    {
        get { throw new NotImplementedException(); // return services; 
        }
    }

    public void RegisterInstance(Type t, object instance)
    {
        wrappedContainer.RegisterInstance(t, instance);
    }

    public void RegisterInstance(Type t, string name, object instance)
    {
        wrappedContainer.RegisterInstance(t, name, instance);
    }

    public void RegisterInstance<TInterface>(TInterface instance)
    {
        wrappedContainer.RegisterInstance<TInterface>(instance);
    }

    public void RegisterInstance<TInterface>(string name, TInterface instance)
    {
        wrappedContainer.RegisterInstance<TInterface>(name, instance);
    }

    public void RegisterType<TRequested, TReturned>() where TReturned : TRequested
    {
        wrappedContainer.RegisterType<TRequested, TReturned>();
    }

    public void RegisterType(Type requested, Type returned)
    {
        wrappedContainer.RegisterType(requested, returned);
    }

    public object Resolve(Type typeOfItem)
    {
        return wrappedContainer.Resolve(typeOfItem);
    }

    public object Resolve(Type typeOfItem, string name)
    {
        return wrappedContainer.Resolve(typeOfItem, name);
    }

    public T Resolve<T>()
    {
        return wrappedContainer.Resolve<T>();
    }

    public T Resolve<T>(string name)
    {
        return wrappedContainer.Resolve<T>(name);
    }

    public object BuildItem(IBuilder<WCSFBuilderStage> builder, object item)
    {
        throw new NotImplementedException();
    }

    public ICompositionContainer CreateChildContainer()
    {
        UnityCompositionContainer child = new UnityCompositionContainer(this);
        return child;
    }

    public void Dispose()
    {
        wrappedContainer.Dispose();
        wrappedContainer = null;
    }
}

We are now in a green state, time to check in.

Abusing Source Control

Agile teams usually check in very often. Some teams check in every time they hit green. I think that is a bit of overkill, unless you have a source control system with NO overhead. I check in when I complete a feature or a story, and usually at a few good, green stopping points in the process, like I have been doing. This was a good stopping point, and my next task is a bit risky, so this is a perfect time to check in.

This is a long enough post, even though I didn't do all that much, that I will call it quits for today. Next post, actually use the UnityCompositionContainer, and then nuke the old CompositionContainer.

Smart Client Software Factory – April 2008 Release is available on MSDN

mpuleio — Sat, 26 Apr 2008 03:25:00 GMT

The April 2008 release of the Smart Client Software Factory is now available at http://msdn2.microsoft.com/en-us/library/aa480482.aspx.

This is a port of the last release (May 2007, if I recall correctly) to VS2008. No new features were added. A few bugs were fixed, and a number of work items from CodePlex were closed.

This release supports Enterprise Library 3.1. It does not support Enterprise Library 4.0. If you want EntLib 4.0 (once it is released) you have the source code, and should be able to get it to work, if you really need to. I would not recommend it, as you will end up with two containers (Unity and the CAB container), which means code bloat and challenges deciding where objects should go.

Converting the Composite Web Application Block to Unity - Ummmm...Oooops.

mpuleio — Wed, 23 Apr 2008 02:57:00 GMT

This is the forth 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.

In the last installment I wanted to remove the following from the ICompositionContainer:

~~static methods~~
~~Builder~~
~~Locator~~
~~Containers~~
Services

We completed the first four. In this installment, we will remove the Services collection, replacing it with using RegisterInstance and Resolve. After that, we will compare our ICompositionContainer to IUnityContainer, see what else we need to do, and may even pull in Unity.

Adding a few new methods

Before we do this, I want to add a generic overload to Resolve and one to RegisterInstance. I like the way the generic calls on Unity look, compared to all the typeof() and casting we have done so far.

I added the following tests, one at a time, and made them pass:

[TestMethod]
public void CanRegisterInstanceViaGenericWithoutName()
{
    ICompositionContainer root = new TestableRootCompositionContainer();
    Foo f1 = new Foo();
    root.RegisterInstance<Foo>(f1);
    Foo returnedFoo = (Foo)root.Resolve(typeof(Foo));
    Assert.AreEqual(f1, returnedFoo);
}

[TestMethod]
public void CanRegisterInstanceViaGenericWithName()
{
    ICompositionContainer root = new TestableRootCompositionContainer();
    Foo f1 = new Foo();
    root.RegisterInstance<Foo>("asdf", f1);
    Foo returnedFoo = (Foo)root.Resolve(typeof(Foo), "asdf");
    Assert.AreEqual(f1, returnedFoo);
}


[TestMethod]
public void CanResolveViaGenericWithoutName()
{
    ICompositionContainer root = new TestableRootCompositionContainer();
    Foo f1 = new Foo();
    root.RegisterInstance<Foo>(f1);
    Foo returnedFoo = root.Resolve<Foo>();
    Assert.AreEqual(f1, returnedFoo);
}

[TestMethod]
public void CanResolveInstanceViaGenericWithName()
{
    ICompositionContainer root = new TestableRootCompositionContainer();
    Foo f1 = new Foo();
    root.RegisterInstance<Foo>("asdf", f1);
    Foo returnedFoo = root.Resolve<Foo>("asdf");
    Assert.AreEqual(f1, returnedFoo);
}

In making them pass, I added the following to the ICompositionContainer interface:

T Resolve<T>();
T Resolve<T>(string name);
void RegisterInstance<TInterface>(TInterface instance);
void RegisterInstance<TInterface>(string name, TInterface instance);

This will help a bit with the look, feel, and style of the code, now for the real work.

Removing the Services Collection

Why do we want to remove the Services collection? Since Unity handles this sort of functionality, we can offload it entirely to Unity. This will cut a bit of code out of our implementation.

Let's do this the simple way, (I like to call it hack and slash development) and just remove the Services collection from the ICompositionContainer interface. This will result in a number of build errors (twenty or so, in fact). However, we can fix each of them easily. Any call to add a service becomes a RegisterInstance call, and any call to get a service becomes a Resolve call. So, we will hack each problem until we are in a green state again. The other option, for the less daring, is to search for all uses of Services, change them one at a time, and make sure we are green at each step. Today, I am feeling brave (read: reckless, or overly caffeinated), so I took the other approach. If I were pairing with someone, they would probably stop me. :-)

Once CWAB compiles, we still need to get the unit test library to compile. <click click click> <swear> <click click click>. The biggest challenge here is that Services.AddNew<T, IT> and RegisterType<IT, T> have the generic parameters in reversed order. Aaargh.

Everything compiles, but I have a problem: 34 unit tests are failing. This is not optimal. Now, why are they failing? After looking at the first few, it looks like I removed Services from the interface, and forgot to remove it from the CompositionContainer. The result is that some tests are still using the ServicesCollection. Oooops.

After removing Services from CompostionContainer, and getting everything to compile again, the test results are.....

Ouch! 40 failing unit tests. That is not good.

However, after some investigation, I can remove a couple of classes from our solution, as they are no longer necessary, and are just causing problems.

ServiceDependencyParameterResolver
ProviderDependencyParameterResolver
ProviderDependencyAttribute
ServiceDependencyAttribute

After removing them, there is a bit of code cleanup required, to remove references. All of the ServiceDependencyAttributes I replaced with ObjectBuilder DependencyAttributes. The ProviderAttributes, I commented out for the moment.

Wow. Progress. we are down to 37 failing tests. After looking at a few of them, where instances were not the same, I changed the SingletonPolicy in Resolve, and we are down to 24 failing tests.

Oh, gotta take a break.

<TimeWarp>Several Days Fly By</TimeWarp>

I got interrupted from getting this working the other day. Now, I am starting with broken tests. I hate that. I guess I was a bit too reckless. Well, I have a few options:

I can continue and see this through
I can timebox to a hour, and then roll back, and try again by taking smaller steps
I can give up now and try again from the last known good state.

I am going to opt for number 1.5: timebox to two hours, and depending on where I am, make a decision.

<timewarp duration="1 hour" />

@#$%^%$#@#$!!!

<timewarp duration="a few days" reason="I needed to think about it" />

I have determined that I got a bit overzealous. For the moment, the Services collection is necessary, and we can remove it once we have Unity in place to provide the necessary functionality. It will stay as part of the interface, and will continue to provide functionality until we no longer need it. However, it will eventually go away. How did I arrive at this conclusion? Well, I could not get the failing unit tests to pass in a reasonable amount of time. Moving the functionality requires a lot more code than is really practical for throw-away code. Oooops. Everyone makes mistakes.

As a result, I need to roll back a lot of changes. Unfortunately, I did not back up everything (or do a check in) before starting down the path of removing the services collection. Net result: I need to roll back everything, and then re-do the first half of this article. Double @#%$@%!

I'll revert and then rework the code up to the section Removing the Services Collection. I'll get the code posted (with the other source code) before I start the next installment.

However, I wanted to post this article sooner rather than later, so folks don't think I have dropped the series. Enjoy.

Unity Shipped

mpuleio — Wed, 09 Apr 2008 02:06:05 GMT

I am a little late to the party, but Unity shipped last week.

Here are a few other posts about it:

Grigori: Unity DI container 1.0 shipped!
Chris: Unity 1.0 is released!

I have used Unity in an internal project here at p&p, as well as a proof of concept re-write of CWAB using Unity. The interface is clean and simple. It does what you want. Configuration is easy. It makes unit testing simpler via de-coupling. Unity rocks.

Converting the Composite Web Application Block to Unity - Intro

mpuleio — Fri, 04 Apr 2008 23:19:00 GMT

A few weeks ago, I decided I needed to play with the Unity Dependency Injection container. I wanted to see how Chris and the rest of the team had designed it and see how usable the container was. I had seen requests on the Web Client Software Factory project's CodePlex site asking for a Unity version of WCSF. Put the two together, and I have a side project, a proof of concept I can legitimately do at work. My eventual end goal is to have the Order Management RI working with a new, Unity-based version of CWAB.

So, I sat down a few Saturdays ago, with CWAB, an early drop of Unity, and started working. After about eight hours I had the basics of CWAB working: there was a container, and a module loader, global services, and module level services. About 3 hours was used figuring out Unity, the differences between it and the container we created for CWAB (CompositionContainer) , and how to get around them. The rest was work, finding bugs in Unity (I filed a few the next day), and quite a lot of fun.

Since then, I have added a few more features, made some forwards progress, and lost ground after being overly optimistic about the impact of a few changes.

Now that I have learned a bit, I wanted to share the information with folks who might be interested in doing this themselves. Rather than trying to remember what I did the first time around, I am going to start over, take a different approach, document what I do as I go, and make a few posts out of this.

Please keep in mind, none of this is tested. Use at your own risk. No Support Available. Danger, Will Robinson! Danger!

This is a proof of concept that I am fairly certain will work, but I am not 100% certain. We will find out as we go. Oh, and I guarantee that there will be breaking changes.

My strategy will be to take the existing CWAB DLL and its unit tests, refactor the container behind an interface, modify the interface to nearly match Unity, and then drop Unity in replacing one implementation of the interface with another. After I get CWAB building and the unit tests passing with Unity, I will open up the code for the RI, replace references, and get it to work.

I will do all of this in an example-driven ~~test driven~~ manner. I am sure I will cheat on occasion, but I will try to be honest and point it out when I do, as well as a reason why.

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

Data-mining for Code Quality Metrics

mpuleio — Thu, 03 Apr 2008 02:30:48 GMT

I spent two weeks between full time projects (still working on the 2 part time projects I am on) looking back at the build logs from the past 6 months (or so) trying to figure out what metrics we have, what we should track going forward, and what goals we should have for these metrics. I came up with some interesting findings.

First, overall unit test code coverage was OK, but not as high as I would like on my projects. Of course, these numbers included generated code, view code, and other things that I usually filter out. Also coverage was fairly flat. For the most part, as we added code, we added tests. This, I think is much better than one of the alternatives, having coverage drop over the course of the project.

Here is coverage for the Application Blocks in WCSF, without axis labels. The Y axis starts at 76% (not zero).

You will see that there was a noticeable drop in coverage part way through the project. That was when we added a new library of AJAX controls. Before the change was made we knew this would happen and accepted the risk. I also worked with the testers on my team to mitigate the risk via more acceptance tests and careful code reviews. And after the change, we trended up, slowly, over time.

In addition to watching coverage over time, I was able to come up with a few indices to watch going forward. Thanks to NDepend, a little bit of work parsing build logs, and Linq, I was able to create seven indices, three of which I will be watching closely on future projects:

Cyclomatic Complexity
Afferent Coupling
Efferent Coupling

If you want a definition for any of these, check out the NDepend site. The index for each of these is the average of the top 10 worst values by type.

Here is a graph of these indices over time for another, un-named project (without the axis labels)

You can see that the first few builds did not have NDepend hooked up properly. Then everything tracks along, relatively stable until about 40% through the project. The Dev Lead on the project was able to tell me what happened on the day that the Cyclomatic Complexity dropped drastically. It was a big change to simplify things.

Do these graphs, numbers, and indices (and all the others that I pulled from the data, but did not share yet) tell me the whole story as far as code quality? Of course not. However, these can all be used as indicators. If complexity trends sharply up over time, there may be a problem we need to investigate. If it stays low, there can still be other problems hidden. However, a little information is better than none.

Now, on to the next project...

Weird COM Exceptions in SCSF/CAB Unit Tests

mpuleio — Wed, 19 Mar 2008 22:17:28 GMT

The SCSF project was getting a weird error with the unit tests that were brought forward from VS2005 to VS2008.

All the unit tests would pass, however the test run would fail with the following error in a special log file:

One of the background threads threw exception: System.Runtime.InteropServices.InvalidComObjectException: COM object that has been separated from its underlying RCW cannot be used.
at System.Windows.Input.TextServicesContext.StopTransitoryExtension()
at System.Windows.Input.TextServicesContext.Uninitialize(Boolean appDomainShutdown)
at System.Windows.Input.TextServicesContext.OnAppDomainUnloaded(Object sender, EventArgs args)

Of course, we had hundreds of these messages, and no way to correlate them with a specific unit test.

After some work, I was able to find a single repro case. After some research, it looks like any unit test that creates a Window of any type will do this. The fix is to add a TestCleanup method to your fixture like this one:

// Added a TestCleanup method to deal with the fact that the code was throwing an InvalidComObjectException
// with the information "COM object that has been separated from its underlying RCW cannot be used."
// Fix is based on this bug logged on Connect.Microsoft.Com:
// http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=318333
[TestCleanup]
public void CleanUp()
{
System.Windows.Threading.Dispatcher.CurrentDispatcher.InvokeShutdown();
}

I know that unit tests that create Windows are not ideal, but for things like CAB and SCSF ( code bases I inherited) it may be necessary.

I hope this helps anyone else who runs into this issue.

The .NET Framework is a bit on the big side.

mpuleio — Wed, 19 Mar 2008 07:42:00 GMT

As anyone who has ever tried to find docs on MSDN already knows, the .NET Framework is big. Real big.

I can see the feedback already: Thanks, Mike for stating the bloody obvious....

Seriously, though, how big is this library that we have been building applications, web sites, critical line-of-business apps, and other frameworks on top of?

Brad Abrams posted all about the Number of Types in the .NET Framework. This includes info about the different versions of the .NET Framework, and the numbers of assemblies, namespaces, types, and members.

As a counterpoint, Patrick Smacchia posted Number of Types in the .NET Framework. using the numbers that he generated with nDepend. (Note from the lawyers: This is a link to an external Web site that provides software. Please note that Microsoft is not responsible for the content of external Internet sites. ) These numbers are a little differnt than Brad's.

With that in mind, it is no wonder that I forget how things in the framework work, every once in a while.

As a personal aside: I am a very happy, licensed user of nDepend, and it rocks. I have used it to help simplify APIs and frameworks like the Composite Web Application Block in WCSF. nDepend allowed me to file bugs against my team's code because methods were too big and complex, or types were too tightly coupled, or classes/interfaces needed to be moved from one assembly to another. One of my current projects is to data mine all the p&p build logs from the past 6 months+ to glean information about our code and improvements we should be making. nDepend results in those build logs provide a lot of data. I may post more about that project later.

Enjoy.

Web Client Software Factory February 2008 Ships!

mpuleio — Thu, 28 Feb 2008 22:25:48 GMT

I know that folks have been reading about the Web Client Software Factory on Blaine's blog and on Glenn's blog. Blaine posted about what we planned to include, back in December with Next version of Web Client Software Factory (WCSF). Glenn had the post at the end of January, Web Client 2.0 closer than you think, and Web Client 2.0, what's the hold up?

So, what is in the latest version of the Web Client Software Factory?

Here is a quick blurb from the front page of our docs, with my comments in Blue:

The February 2008 release of the Web Client Software Factory is an update to the June 2007 release. The following are the major changes:

Added user interface responsiveness guidance. The guidance includes documentation, Web controls, QuickStarts, and a new reference implementation that demonstrate how to incorporate Microsoft ASP.NET AJAX technologies in your Web applications to provide a richer user interface experience.
Added support for the Model-View-Presenter pattern in user controls and master pages. The Composite Web Application Block includes a new Dependency Injection mechanism that facilitates the implementation of the Model-View-Presenter pattern in Web controls and master pages. The guidance package also includes new recipes that help developers create master pages and user controls that implement the Model-View-Presenter pattern. By using the Model-View-Presenter, developers can extend the testability surface to user controls and master pages.

Dependency Injection also works in ASMX Web Services hosted in a WCSF web application project

User controls can be reused across modules. Developers can build Web pages made up of user controls from different modules.

There is an example of this in the Order Management Reference Implementation

Updated the Composite Web Application Block. The main changes include the following:

Improved performance
Support for services registration through configuration
Support for type mapping for dependency injection

Type mapping was a no-brainer to add. We also needed it to show a few of the deeper concepts around MVP.

The performance improvements are the part of how the new Unity project works deep under the hood. Chris Tavares and worked with the WCSF team on the performance enhancements. Later, Chris went to start the Unity project, which has evolved into a great tool from what I have seen. I know the next question is "When will WCSF support Unity?" My answer is as soon as we can do a complete re-write. Out of the box, Unity provides a lot of functionality that CWAB provides. To properly use Unity, we would need to throw out a lot of the CWAB code, and re-do it.

The ability to add a service via config was requested by the community, and is shown in the Order Management Reference Implementation.

Updates to the Add Business Module and Add Foundational Module recipes. These recipes now include a new option to create a separate project for the modules’ public interface.
Updated the patterns documentation topics. The main changes include two new pattern description topics, Inversion of Control and Module Interface Separation, and it updates to the Model-View-Presenter topic.
Included additional guidance for several technical concepts. The technical concepts covered are views testability, modularity, autocomplete, validation, and search. The guidance consists of documentation, QuickStarts, Web controls, and How-to topics.

These concepts were shipped previously as "Bundles" on our CodePlex community. We will be releasing new, updated VS2008 versions of these bundles on MSDN in the near future, but all the content is in the factory. The bundles are so folks can get a small taste and look at a single feature or concept in isolation.

Added support for Visual Studio 2008 to the guidance package.

VS2008 and and .NET 3.5 support was asked for very loudly by customers.

Testing Guidance

Something we do not talk about enough is the fact that we are releasing some guidance on how to test web applications. First, since we do most development via ~~TDD~~ EDD (Example Driven Development), we have quite a bit in the way of unit tests. There are a few exceptions, where we intentionally do not include unit tests as we do not want to clutter a QuickStart example with another concept that may hinder understanding of what the QuickStart is about.

We are also shipping acceptance tests. In a few projects, these acceptance tests are manual test scripts in the form of a Visual Studio Manual Test. In others, we have completely automated the acceptance tests using

<TheLawyersMadeMeSayIt>

Note: this is a link to an external Web site that provides software that can be used to write acceptance tests. Please note that Microsoft is not responsible for the content of external Internet sites.

</TheLawyersMadeMeSayIt>

the WatiN (Web Application Testing in .NET).

To compile the test projects and run the tests, you will need VS2008 Professional or Team System, and to download the WatiN binaries, and copy the DLLs to the Lib folder (which our help describes with more info). The upside is that anyone can see how we are doing functional/acceptance testing of our sample applications. Of course, there is a lot more to testing than just acceptance testing, but it is a start.

Other resources

The WCSF page on MSDN
The WCSF Community on CodePlex
If you just want to peruse the docs, check out the WCSF Documentation download page

You will also want to check out what Blaine and Glenn say about the release:

Blaine's post: Web Client Software Factory Shipped
Glenn's post: Web Client Software Factory 2.0 Shipped

Developing a ASP .NET Control with client capabilities

mpuleio — Wed, 31 Oct 2007 20:16:25 GMT

Brian J. Cardiff ( from Clarius Consulting) is one of the developers on the Web Client team. He has asked me to post an article for him, since he does not have a blog (yet).

Here it is (with some re-formatting):

Developing a ASP .NET Control with client capabilities (using ASP .NET Ajax Extensions support)

Since the AjaxControlToolkit appears, creating extenders control like Autocomplete (AjaxControlToolkit) or Contextual Autocomplete (Web Software Factory) is a task that involves more work in JavaScript and Metadata that classic .NET programming.

In this post I will point out some of the key aspects to create, a Control that takes advance of the ASP .NET Ajax Extensions. The post is based on the RealTimeSearchMonitor control located inside the Search Bundle of the Web Software Factory. So I suggest downloading and opening it while you read the post, just to take a quick look at it.

When you want to create a control that will reside on client side, what would you need? (and where it is implemented in RealTimeSearch project)

ASP.NET Control that implements IScriptControl

RealTimeSearchMonitor.cs

A JavaScript file that will define classes and/or function for the control.

RealTimeSearchBehavior.js

Some lines of JavaScript code to instantiate a client side object.

These are generated from GetRealTimeSearchMonitorScriptDescriptor protected method.

(Optional) ASP .NET Control Designer

RealTimeSearchDesigner.cs, metadata all around and type converter.

The IScriptControl interface defines two method:

IEnumerable<ScriptReference> GetScriptReferences()

This indicates that a reference to RealTimeSearchBehavior.js file should be included

In the response you will have:

<script type="text/javascript" src="/ScriptResource.axd?d=…(some identifier)…" ></script >

IEnumerable<ScriptDescriptor> GetScriptDescriptors()

This calls GetRealTimeSearchMonitorScriptDescriptor protected method.

In the response you will have:

Sys.Application.add_init(function() {

$create(

RealTimeSearch.RealTimeSearchBehavior,

{"controlsToMonitor":[

{"TargetId":"ctl00_DefaultContent_CompanyNameTextBox",

"Callback":"javascript:__doPostBack(\u0027ctl00$DefaultContent$CompanyNameTextBox\u0027,\u0027\u0027)",

"Validators":["ctl00_DefaultContent_CompanyNameRegexValidator"]},

…(more controlsToMonitor elements)…}],

"interval":700}, null, null,

$get("ctl00_DefaultContent_CustomerRealTimeSearchMonitor"));

});

What does the GetRealTimeSearchMonitorScriptDescriptor method do?

Using properties of the RealTimeSearchMonitor it generates the info that the control will need in the client side. In this case: resolving control's ClientID, Callback for the specified event and related validators to each controls (see ResolveControlMonitorParameter method). It's no magic but a very important point where all get wired.

The ScriptComponentDescriptor has to be related with a DOM element in the client side, so our control will also generate an empty DIV, this is done in the Render method.

Although IScriptControl interface is implemented

Although IScriptControl interface is implemented you have to call RegisterScriptControl and RegisterScriptDescriptors methods in the ScriptManager of the page in order to get our GetScriptReferences and GetScriptDescriptors called respectively. The former is done in the PreRender and the later in the Render method.

Conclusions

It's good to have a simple (but useful) example of a control with client capabilities using ASP .NET Ajax Extensions. There is quite a good infrastructure to develop your own controls, go ahead and give you a chance to know it and use it!

Brian J. Cardiff (Clarius Consulting)

brian.cardiff@clariusconsulting.net

Please feel free to leave comments here, or email Brian directly.

The future of WPF Guidance

mpuleio — Mon, 29 Oct 2007 22:53:57 GMT

There is a lot of new information, all announced today, about the future of Acropolis, CAB, and WPF guidance from patterns & practices. This comes about after a lot of internal discussions between the patterns & practices Client / User Experience team and the Acropolis team.

If you want to know what is going on, start with the Acropolis team blog, and their article A new phase for the Acropolis project. Then read Glenn's post, WPF Composite Client, it's coming!

Between the two, there is a lot of information: how things have changed with Acropolis, a little bit of guidance about what to do now with apps you are developing, and the future plans of p&p and Acropolis.

If you have feedback, either post comments here, add comments to Glenn's post, or send email to Glenn (his address is at the end of his post).

[Note: Blaine also is linking to these articles in his own post.]