Espresso Fueled Agile Development : ASP.NET AJAX

Who is using WCSF?

mpuleio — Wed, 03 Dec 2008 21:48:51 GMT

Blaine and I would like to ask the community to let us know "who is using WCSF?" We know that WCSF has been fairly successful based on:

WCSF has been downloaded a few times (ok, it is really many thousands of times)
The discussion forums on CodePlex are fairly busy
Direct customer engagement with a number of companies

However, there are a lot of folks who are using WCSF that we do not know about. Since we get requests all the time about who is using WCSF, the size of projects, the size of dev teams, etc, we would love to collect some more data and statistics. So, if you have used or are using WCSF on a project, let us know via comments, email, or discussions on CodePlex. If you have stopped using it, please let us know why, so we can possibly address concerns.

To make things simple, I have created a thread on the WCSF CodePlex discussion forum so you can easily provide feedback: http://www.codeplex.com/websf/Thread/View.aspx?ThreadId=41405

Thanks.

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]

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.

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.

Converting the Composite Web Application Block to Unity - Clean Up ICompositionContainer

mpuleio — Thu, 10 Apr 2008 02:06:05 GMT

This is the third 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 post, we started getting closer to my eventual goal. However, we still need to get rid of the static methods, Builder, Locator, Containers, and Services.

Why?

Static methods will make the necessary refactorings a pain in the.... well, a pain.
Builder and Locator are handled by Unity internally, and we no longer need to deal with them directly.
Containers will just be registered in the root container by module name, and we can use the WebClientApplication.FindModuleContainer method when we need to.
Then there are CWAB Services. These services will probably just go away. Global Services are types that are Registered on the Root Container as singletons, and module services are types registered on the appropriate Container as singletons. This will be really simple once we get Unity tied into the solution.

Once we get rid of these items on the interface, we will want to add a few from the IUnityContainer, namely CreateChildContainer, and at least a few overloads (if not all of them) for RegisterType, RegisterInstance, and Resolve.

Then, we will add a new type of container to the project, a CWABUnityContainer, and maybe a CompositionContainer factory. The CWABUnityContainer will be a facade that implements ICompositionContainer and hides a real UnityContainer under the hood. After that, things should be simple, allowing us to delete the old container and its code, and then do a bit of re-organizing.

Note: Since this is a proof of concept, not what I would call "shipping code", I have turned off creating XML comments in the solution. With the volume of changes, I was getting annoyed with all the warnings.

Removing Static Methods from CompositionContainer

There is only one static method on CompositionContainer, and it relies on the Locator property of the container object parameter to work. In removing this, we can simplify the type, and remove the only dependency on the Locator property. Let's change BuildItem to be a public, non-static method, and add it to the ICompositionContainer interface for a little while.

Everything compiles. Tests green (except for the ones I had commented out near the end of the last article.

Removing ObjectBuilder specific parts of the interface

Let's do these one at a time, starting with Builder. Comment it out in the interface, and....

Two parts of the test fixture fail to compile:

CreateRootContainerInitializesContainer needs a line commented out, since we changed the semantics of the method
MockWebClientApplication needs a change to the ApplicationBuilder property to return null for the moment, with a comment to come back later.

Now we can compile, and run the tests, and we are green. However, I did notice something that I want to take care of before I go any further.... IWebClientApplication has an ApplicationBuilder and a PageBuilder, which can go away. The Container will handle the responsibilities of these two properties. If we delete these properties from the interface, the MockWebClientApplication and WebClientApplication, we get some compile errors in WebClientApplication, which lead us down an ugly path. Instead, we will leave these properties ONLY in WebClientApplication, and make a note to delete them later.

Compile -> Good.

Tests -> Green.

Next Step, the Locator...

If we remove it from the interface, we have compilation problems in WebClientApplication.BuildItemWithCurrentContext where we call BuildItem. Let's roll back, change the signature of BuildItem to not have a locator, and the implementation to use the current container's locator, and then re-do the change. Again, we will leave the property only on the CompositionContainer, even though it is not part of the interface, and add a few comments. After a quick change to the test CreateRootContainerInitializesContainer, everything is green, and all tests pass.

The Containers collection

If we remove the Containers property from the ICompositionContainer interface, we have problems in the ModuleLoaderService. The ModuleLoaderService understands how the CompositionContainer works, and can add new containers (one for each module) to the collection. We also have challenges in the DefaultModuleContainerLocatorService, where we need to find a container in the collection. If we think about how Unity works, both of these problems can go away if we find another another way to get child containers, and to create child containers. Unity has the Resolve method, which can take a name parameter to get a named instance of an object (this handles getting a child container). We also have the CreateChildContainer method, to help with the creation, as well as RegisterInstance to give a created instance a name to use later.

Let's roll back removing the Containers property, add the RegisterInstance and Resolve methods (that use a name) to the interface, test them, then add the CreateChildContainer method to the interface, and test it. Once we have those pieces, we can re-work ModuleLoaderService and DefaultModuleContainerLocatorService to use the new methods. Once we do all that, we can remove Containers from the ICompositionContainer interface without problems.

So, let's start with RegisterInstance. Since I know whatever implementation I come up with is a throw away implementation, and it only needs to work well enough NOT to break the existing code, I am going to keep this simple.

First, a unit test added to CompositionContainerFixture:

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

This tests for the behavior that Unity will have. I will add the following to the ICompositionContainer to get it to compile:

void RegisterInstance(Type t, string name, object instance);

And then add the stupid implementation:

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

Everything compiles, and the test fails, horribly.

Now, to get the test to pass, RegisterInstance becomes:

private Dictionary<string, object> _registeredInstances = new Dictionary<string, object>();
public void RegisterInstance(Type t, string name, object instance)
{
    _registeredInstances.Add(String.Concat(t.FullName, name), instance);
}

Now, I know that is an ugly, bad, horrible monstrosity of an implementation. It is also the simplest thing that will work. :-) I also know I could use OB to do this, but again, I am keeping things simple, knowing I will throw away the implementation in a few hours.

Resolve changes a bit too. I added an overloaded version, and then made the unit test above pass by making the code look like this:

public object Resolve(Type typeOfItem)
{
    string temporaryID = Guid.NewGuid().ToString();
    return Resolve(typeOfItem, temporaryID);
}

public object Resolve(Type typeOfItem, string name)
{
    string key = String.Concat(typeOfItem.FullName, name);
    if (_registeredInstances.ContainsKey(key))
    {
        return _registeredInstances[key];
    }
    
    PolicyList policies = new PolicyList();
    policies.Set<ISingletonPolicy>(new SingletonPolicy(false), typeOfItem, name);
    policies.Set<ICreationPolicy>(new DefaultCreationPolicy(), typeOfItem, name);
    policies.Set<IPropertySetterPolicy>(new PropertySetterPolicy(), typeOfItem, name);

    return _builder.BuildUp(
        _locator,
        typeOfItem,
        name,
        null,
        policies);
}

Compile. Run Tests. We are Green.

Now to add CreateChildContainer. First, we need a unit test:

[TestMethod]
public void CanCreateChildContainer()
{
    ICompositionContainer container = new TestableRootCompositionContainer();
    
    ICompositionContainer child = container.CreateChildContainer();
    Assert.IsNotNull(child);
    Assert.AreNotSame(container, child);
}

To make that compile and then pass, I added CreateChildContainer to the interface, the class, and then implemented it. Simple. And we are Green again.

Next step: remove from ICompositionContainer the Containers property, compile, and it fails. This requires minor tweaking to the ModuleLoaderService and DefaultModuleContainerLocatorService. Now, we compile. However, the Containers property is still on the CompositionContainer. After we remove it from there, we have to fix a lot of unit tests so that they compile (and removing a few that no longer make sense, semantically). This is simple, but tedious. <click> <click> <swearing> <click> <click> ...

Ok, we are now compiling and all unit tests pass.

I need a break, so we will cut this a little shorter than I had hoped.

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

static methods
Builder
Locator
Containers
Services

We completed the first four. In the next 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.

Web Client Software Factory Guidance Assets are now Available on MSDN

mpuleio — Wed, 09 Apr 2008 20:19:14 GMT

Some of you may remember that waaaay back in October (and earlier) the Web Client Software Factory team was shipping these things called "bundles". A bundle was all a developer needed to get started and learn about a single concept, like the Model View Presenter pattern in a web application, or contextual auto-complete. These bundles were released for VS2005 and .NET 2.0 on the WCSF community CodePlex site.

Now, the same bundles for VS2005 with .NET2.0 and new bundles for VS2008 with .NET 3.5 are available on MSDN's Web Client Software Factory page. However, due to factors I do not understand and that are beyond my control, we are now calling these "Guidance Assets".

The first question everyone is going to ask is :

"How are these different from the Web Client Software Factory - February 2008?"

The Guidance Assets for .NET 3.5 are identical to the same assets inside the WCSF February release. This packaging just allows developers to grab one or two pieces of the factory at a time, or to share with a co-worker to get them up to speed on a concept. For example, the Web Client Contextual AutoComplete Application Block for .NET Framework 3.5 is EXACTLY the same as the Autocomplete Quickstart in the factory, with everything you need to get started and stand alone documentation. The .NET2.0 versions of the assets are identical to what we shipped in October on CodePlex (in fact, they were copied from CodePlex to the MSDN download center).

Why did we post the bundles on MSDN?

A number of customers complained that they wanted to use the bundles but their corporate policy does not allow them to use anything from CodePlex or other open source sites. However, MSDN is a trusted source in their companies. To help these customers, we have have two distribution channels for identical assets. :-)

Blaine has already blogged about this, Web Client Bundles for .NET 2.0 and .NET 3.5 Available on Download Center

Here is a comprehensive list of click-able links for all the ZIP files:

.NET 3.5 Assets for Visual Studio 2008: (All these are included in the Feb release of the factory, Web Client Software Factory - February 2008)

.NET 2.0 Assets for Visual Studio 2005: (These are what we released in October-ish)

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

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 with Side by Side Support

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

When we originally released the Web Client Software Factory February 2008, there was an issue for a number of folks. If you had VS2005 installed with the October release of WCSF, you could not install the February release on VS2008 without uninstalling the October version. After some feedback fromcustomers who need to support both WCSF 1.1 apps and WCSF 2.0 apps, we have re-released the factory installer. The install no longer forces an un-install of the Oct release, allowing side-by-side support. Go get the refreshed MSI from the download center.

Blaine recently blogged about this too.

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.

WCSF: Insights and Plans

mpuleio — Mon, 15 Oct 2007 21:36:57 GMT

There have been a lot of posts recently about WCSF, spurred on by our recent releases. Here are a few highlights with my comments about each:

Developer Hands-on Labs available for WCSF June 2007 Release - Blaine

These have been on the back burner. They had been "almost" done for quite a while, and are finally out the door.

Web Client Bundle Quality Checkpoints - Blaine

I worked with Blaine on drafting this. (I actually threatened to post it if he did not do so soon). It gives some insight into what we do around testing each and every one of our releases.

More Web Client goodness shipping, WCSF 2.0. - Glenn

A re-cap of what we have shipped recently, as well as future plans for the team.

How-To: Web Client Software Factory (WCSF) June 2007 & Visual Studio Orcas Beta 2 - Ezequiel

Necessary reading if you are running Orcas and want WCSF to work.

More Web Client bundles shipped

mpuleio — Tue, 09 Oct 2007 18:30:17 GMT

Yesterday, we posted the Composite Web Client Library and the Composite Web Client Automation bundles.

The Composite Web Client Library bundle is the source code and binaries (strong named and signed) for the Composite Web Application Block, and a few other useful libraries, including sample ASP.NET AJAX extender controls. A few of the big changes include the abililty to do dependency injection (sort of, see my other post on Breaking Changes in CWAB) on Pages, MasterPages, and UserControls.

The Composite Web Client Automation bundle is a new version of the Web Client Software Factory's guidance package. We have enabled creating composite web applications by adding the ability to create MVP-style Pages, MasterPages, and UserControls. We also have a recipe to enable ASP.NET AJAX on an existing solution (without needing to manually hack the project and solution files).