I'm finally recovering from the 2007 Calgary Code Camp. It seemed like every presenter I talked to, including myself had very little sleep all weekend. A big thanks go out to James Kovacs and the organizing committee of the code camp, it was tons of fun and I am already looking forward to next year.

My presentation on Windsor Container went well. I am unsure if I am going to talk over screencasts during my presentations anymore as it is to slow and I am more confident in my typing and presenting abilities.

For now I am going to release a screencast on setting up a simple component that was intended for the code camp attendees. You can download it here you can download the code for my presentation here. I am open to any feedback or questions that anyone has on Windsor Container, please contact me and I will do my best to answer.

A couple of attendees at my presentation asked if Windsor Container supported constructor based dependency injection and the answer is absolutely! I will be coming out with another screencast soon that will explain inversion of control more in depth and show how you can refactor towards using Windsor Container.

If you are stuck using MSTest as your unit testing framework you may run into problems if any of your tests depend on external files.

MSTest creates a TestResults directory:

A directory made up of your login name, computer name and a timestamp:

and a In and an Out directory:

 MSTest then copies all referenced assemblies to the Out directory and runs the tests in that directory. The problem is that MSTest does not recognize any XML configuration files (besides App.config) as dependencies and they are not copied to the Out directory so your test fails.

To remedy this you need to specify your external dependency as a deployment item in an attribute at the beginning of your test and specify the path to the deployment item:

[TestMethod]

[DeploymentItem("WindsorTestConfiguration.xml")]

public void ShouldUseDependencies()

{

    IWindsorContainer container = new WindsorContainer(new XmlInterpreter(@"WindsorTestConfiguration.xml"));

    Assert.IsNotNull(container);

}

At work I was given the opportunity to build a new piece of complex functionality for the application that I have been working on for the last 6 months. After taking the excellent Nothin But .NET training course instructed by Jean-Paul Boodhoo I decided to try building the new functionality using the domain driven design techniques I learnt at the course.

To me, the domain driven design section of the course was a real eye opener, it taught me to concentrate on the problem I was trying to solve and not worry about infrastructure code. 

To start off the process I met with the domain expert and tried my best to come up with a ubiquitous language that made sense to both of us. It was hard not to talk about interfaces and classes with the domain expert. I even noticed that the domain expert at times would try to translate things into technological terms for me.

Next I created a new solution completely separate from the solution that already existed. My reason for doing this was that before I even started trying to create the new functionality for our system, there was data waiting for me in the database whose sole purpose was to assist me in solving the problem at hand. That data to me, would only distract me from solving the problem and have me worrying about how I was going to get it out of the database.

I wrote my tests first and refined the design of the domain a little at a time only when a new problem presented itself. The next thing I new the problem I was trying to solve had solved itself slowly using tests and small concentrated refactorings. The hardest part was not getting ahead of myself and trying to stay disciplined throughout the process.

I am pretty proud of the solution I eventually came up with although I know that there is room for improvement in the steps I took to solve the problem and the code that I eventually came up with. If you have done domain driven design at work and have any tips for me I would love to hear them. This experience was highly rewarding and I'm not sure if I can go back to the way I coded before.

After learning about the MbUnit plugin for ReSharper from JP at the Nothin But .NET bootcamp, I was really happy to see that James Kovacs has come up with a VsTsUnit plugin for Resharper. If you are forced by your client to use the MSTest for your testing this is something you should install to make your life easier.