Learning MSBuild

Google didn't seem to be quite as helpful as it usually is this time round. I was in the position where I needed to learn MSBuild as fast as possible however most of the information I was finding was pointing to the Microsoft site. Now don't get me wrong, there is a heap of information here, but it was a bit of an overload of info.

Given a solution or project file that you've already created it is a simple matter to call MSBuild against that particular file, but what I really wanted to do is have a separate build file that would do the lot.

So how did I go about picking it up?

I started with a REALLY simple app (can't stress enough how simple it was) and added an XML file to  the solution that would act as my build file. On a side note, I later changed the file extension to .proj and the file maintained intelisense.

I then copy/pasted the following lines into the file:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>

The following is an overview of my observations of how I got my app to build and execute tests.

The first thing I played with was indicating which solution to build. This is what I ended up with:

<PropertyGroup>
    <SolutionDir>..</SolutionDir>
    <SpecificSolutionToBuild></SpecificSolutionToBuild>
</PropertyGroup>
<Choose>
    <When Condition="'$(SpecificSolutionToBuild)' == ''">
        <ItemGroup>
            <SolutionsToBuild Include="$(SolutionDir)\TeamCityTestApp1.sln" />
            <SolutionsToBuild Include="$(SolutionDir)\TeamCityTestApp1Alternate.sln" />
        </ItemGroup>
    </When>
    <Otherwise>
        <ItemGroup>
            <SolutionsToBuild Include="$(SolutionDir)\$(SpecificSolutionToBuild)" />
        </ItemGroup>
    </Otherwise>
</Choose>
<Target Name="Compile">
    <MSBuild Projects="@(SolutionsToBuild)" Properties="OutputPath=$(OutputDir);Configuration=Release;DebugType=none;" />
</Target>

The above code introduces the Choose element and the Properties attribute in the MSBuild element.
Next I wanted to set the build output directory. Here's what I came up with:

<ItemGroup>
    <FilesInOutputDir Include="$(outputDir)\*"></FilesInOutputDir>
</ItemGroup>
<Target Name="CleanOutputPath">
    <Delete Files="@(FilesInOutputDir)" />
</Target>
 
<Target Name="Compile" DependsOnTargets="CleanOutputPath">
    <MSBuild Projects="@(SolutionsToBuild)" Properties="OutputPath=$(outputDir);Configuration=Release;DebugType=none;" />
</Target>

It was while I was figuring this out that it dawned on me that if I need to refer to multiple items then I always need to create an ItemGroup.

The next thing that was essential to figured out was getting unit tests executed. This was my first introduction to the use of custom build tasks.
For this I downloaded MSBuild.Community.Tasks.msi from msbuildtasks.tigris.org.
To get this working all you need to do is import the MSBuild.Community.Tasks.Targets at the top of your build file like so:

<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />

 and to call:

<Target Name="RunUnitTests" DependsOnTargets="Compile">
    <ItemGroup>
        <AssembliesToTest Include="$(OutputDir)\TeamCityTestApp1.Tests.dll" />
    </ItemGroup>
    <NUnit ToolPath="$(NUnitToolsDir)"
            DisableShadowCopy="true"
            Assemblies="@(AssembliesToTest)"
            OutputXmlFile="$(BuildDir)\UnitTestResults.xml"/>
</Target>

In this example I've created an item group to encompass which assemblies to test. In this situation this isn't really required as I'm only testing one dll, however if I were testing multiple dll's then this would be the approach to use.

I know a lot of this information was fairly basic, but thought it might be useful for those who haven't worked with msbuild before.

Enjoy!

Agile Needs To Be Driven From The Top

Last year I read an article on how Agile Development Must Be Driven from the Top.

For the last couple of months (approx. 9) I have been acting as Scrum Master, on the biggest project I've been involved in, and I have been battling this very thing. The overall project is being run in a classic waterfail (aka waterfall) approach and for some reason my colleagues and I thought we could convince our client that we could do our component of the project in an agile fashion. Boy were we wrong!

The project has shown all the classic symptoms of a classic waterfail project and as you could expect requirements were always hard to come by until certain "milestones" were reached. My thoughts were that shouldn't be a problem, we'll create user stories that cover the requirements that are known now and cover the gaps with extra stories later. In theory this should be fine, except for one tiny problem...

The agile approach we were using wasn't being driven from the top!

The project manager we were under, while he was happy for us to drive the agile approach, he and some of his own colleagues didn't truly understand the benefits of the metrics that can be derived from a well run agile methodology. He was too focused on sticking to his original plan - one massive development phase followed by a massive testing phase.

Where are things at now? I have gone back to development, the client has fallen back to complete waterfail approach. They are evening phasing out the end-to-end tests in favour of manually testing during the test phase.

So what did I learn from the experience? Unless management are TRULY willing to adopt the requirements of following an agile approach, don't waste your time.

Notes on Agile Australia - Day 1

This has taken way too long to get around to doing, but here are my notes on Agile Australia day 1.

Keynote 1

Alistair Cockburn - alistair.cockburn.us

Discussed a number of perspectives of agile: Games, Craft, Flow Management and Knowledge Acquisition

#1 - Games
Just like games, agile software development requires positioning, moves and strategies.

Quite often there are two conflicting subgoals:
Deliver this system
Setup for the next game

You also need to adapt to your situation by understanding how your project can be classified. Classification is gauged by the criticality of the project and the number of people that require co-ordination.

#2 - Craft
Craft teaches you to pay attention to our skills and to the medium in which they learn.

People learn skills in 3 different stages
1. Shu: Learn a technique
2. Ha: Collect techniques
3. Ri: Invent/blend techniques

Considering that I work for Readify, I thought this had a natural affinity to our slogan Discover. Master. Influence.

#3 - Flow Management
Design == manufacturing if Inventory == Decisions
We need to learn from the queues in our process. Identify where the bottlenecks and make decisions but make them quickly

#4 - Knowledge Acquisition
The Big bang theory is a late learning strategy
In designing the solution we gain knowledge early

Keynote2

Rob Thomsett

Every company is ready for Agile... they just don't know it!

How do you certify someone in common sense? [I think this is more of a provocative statement, as there is more to obtaining certification in an agile methodology]

Some easy tests for a good development process
 - Simplicity
 - Transparency

We need to close the lines of communication.

Governance gives the semblance of control.

(Rob if you end of up reading this please be aware that you ask the audience"Is that OK?" way too much!)

Rock Road to an Agile Transformation

Daniel Oertli

While it was not quite what I was looking for or anticipating, it was an interesting talk with a nice use of pollev.com (even if the execution didn't quite work).

Daniel gave a run down of the primary questions that he had to think through when taking the company from Ground Zero through to delivering results through to scaling the model and finally leading to sustaining performance.

A few key phrases that I got out of the talk:

• Plans are nothing, planning is everything
• You want to be customer centric not customer driven
• Agile is a cultural change enabler
• Agile requires delegation

How Agile can go terribly wrong

Martin Kearns

Among other things Martin drew a picture (literally) of three teams with a different type of leader in each.
Team 1 has a leader who chains the team to them,
Team 2 has who claims to trust the team. But this is not sustainable as it take too much energy.
Team 3 has a leader who is involved. This seems great, however if a member leaves the team and is replaced by someone with different values all hell can break loose.

We's stopped being agile because we've started being purists.

Something to be aware of is that during the standups people can fall into the habit of talking about themselves and not about the story.

A team is only successful as its least committed member.

LiveAccounts DevOps - Continuous Delivery in the Real World

MYOB

Wasn't sure if I'd pick anything new up in this one as I already new the benefits of continuous delivery. For those of you who are still debating the whether to introduce the practice into your development process, MYOB were able to quadruple the through put of the development team.

Agile Games

Kane Mar

Game 1: Failure Bow
This was an odd game and very simple.
Each of us had to come up with a way of acknowledging our failure. Some of us were a little shy others not so much
We then split into groups and proceeded to throw a ball around the group with the understanding that if we drop the ball we'd perform our "bow". We then had another object introduced to throw around and then were only allowed to catch with one hand.

Game 2: Go
This is more or less a team coordination game.
Starting with one person (P1) on the team they had to point to another team member (P2) to indicate that they were going to stand in their spot. P1 is not allowed to move until P2 has said "GO".
However you can not have two people standing in the same spot, so P2 has to point to another team member (P3) to indicate they wanted to stand in their spot.
And so the pattern continues.

From my point of view this was a coordination exercise. If everyone was paying attention to what the team was doing then it was easy enough. However, it only took one person to stuff the hole thing up.

Game 3: Marshmallow Tower
For more information see: marshmallowchallenge.com

This was a very interesting challenge. A challenge that I consider I failed. While I knew that I needed to "inspect and adapt", it was very easy to fall into the waterfail approach of discuss... and then fail.

Anyway, there's a few thoughts on Day 1. Hopefully my thoughts on Day 2 will arrive a little quicker than these did!

Enjoy!

Matt

Trial and error vs. Inspect and adapt

I recently watched a video on using an agile approach to work in a non-software environment (ABC Nightline - IDEO Shopping Cart). There were a bunch of very cool catch phrases that were used one of which really stuck to mind...

"Enlighten, trial and error succeeds over the planning of the lone genius"

While this is a might be great from a non-development perspective, I don't think that it is quite right from a development perspective. It implies that the group don't really know the direction they're going and that they could get it wrong. This doesn't work for development. The development team should always know the direction they are going otherwise they increase the chance of incurring technical debt. I prefer the well known phrase, Inspect and adapt.

What I do love is the reference to the planning of the lone genius.

A great dig at waterfall! :)

Don't Deliver To Promises

The other day I read a great article on building trust one iteration at a time. Considering I'm operating as Scrum Master for the development team in a large waterfall project, something that stood out to me in this article was a comparison of Waterfall to Agile.

In a waterfall delivery, all progress reports are proxies. You’re reporting on intangibles–designs, test cases, or code that isn’t fully integrated or tested. This is all reporting on faith, because it is not verified by working software.

Just this morning this was proven true. A waterfall PM was tracking the progress of some work with a BA who  said "I'm waiting on John. He told me that he'd have it ready for me by COB yesterday. In fact he said the same thing last week."

I had a quiet chuckle to myself.

Installing Pre-Requisite Assemblies For VSTO Applications

If you've read my previous post How to Deploy a VSTO Word Template Application you would probably be thinking cool, nothing else to it. But...

If you were like me and were trying to install it into an environment that had absolutely none of the pre-requisites then I'm guess you would be getting an exception that went along the lines of "The common language runtime could not be loaded by ... "

What the heck does this mean? If you were like me, you'd be scouring the web and coming up with pages that reference the pages you've already looked at. Useless!

It wasn't until a mate at Readify, Jake Ginnivan, that if the box doesn't have the .net framework then it can't even read the VSTO file to know what to do.

The solution: the user needs to run the Setup.exe manually! Once this is done, the user can then go and open up the office document (mine was a word template). Now that the pre-requisite assemblies are there the VSTO app can now get installed. Hallelujah!

I hope this has helped.

Enjoy!

How to Deploy a VSTO Word Template Application

I recently had to build a word macro that read an Excel spreadsheet and produced a series of PDF files that were then sent out to an email that existed within each row.

The approach that I took was to develop a VSTO Word Template application that would step the user through the process of selecting the spreadsheet, reading the data and finally processing the data.

Step One - Creating the Application
To create a Word Template application is relatively straight forward. From the New Application dialog browse for Office > 2007 > Word 2007 Template. You should now be presented a .dotx file that you can now customise to your hearts content.

Step Two - Adding the Controls to Template
Not having worked with a VSTO application before I simply copied the RichTextContentControl from an example application I found. However, like any .Net application all the controls that can be utilised in the Word Template can be found in the toolbox. (Thanks Mr Obvious!)

Here's what mine looked like...

Step Three - Adding the Actions Pane Control
Just having some controls embedded in a template isn't going to do a lot, you need some way for the users to interact with the template. This is where the Actions Pane Control comes in play.

Here's what mine looked like...

So you can basically added all manner of controls to the Action Pane and treat it like a Windows Form.

Step Four - Deploying
Developing all of the above is fairly straight forward, just like developing a web/win app, F5 and away you go. But how to deploy that was a little different.

Googleing "How to deploy a VSTO word template application" and the like continued to give me information on the problems people were having. Not very helpful! Thankfully due to the awesome resources available from Readify I was eventually pointed to the following links:

• Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows Installer (Part 1 of 2)
• Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows Installer (Part 2 of 2)
• Deploying Solutions for the 2007 Office System with ClickOnce Using Visual Studio 2008 Professional

These links are your one stop shop for deploying VSTO applications.

Enjoy!

[Edit]
I also came across these screencasts yesterday. They provide an awesome walk through of the deployment process.
VSTO: Deployment via ClickOnce screencast and VSTO: Deployment via SharePoint

Next: Installing Pre-Requisite Assemblies For VSTO Applications