Well here we are; 2011 is drawing to a close and every blog seems to have an end of year review, who am I to buck the trend? So here are the things of note from my 2011, going from vaguely technical to totally personal:

The Wonders Of Agile

The members of our development team in my day job have been pushing agile for a while now, but it’s only been during 2011 that I think we got the process down and finally started to get the buy-in from outside the team that you really need to make it work. The benefits have been obvious and we won’t be going back any time soon!

Get in the SCRUM

Continuous Deployment

This has been central to the success of the agile process for us. While we’re nowhere near the holy grail of continual deployment to live, it cannot be overstated the difference that continual deployment to test has made. If a TFS user story is marked as completed the product owner knows it is available to them, which saves plenty of problems with forgotten deployments causing a lack of confidence from the product owners. This is made possible by the power of TFS build and it takes a matter of moments to set up for new projects.

Setting up continuous deployment in TFS

WiX

If you’ve been following the blog you already know I’m a bit into WiX! With our current work environment we have no control over staging or live servers and so creating proper installers has been a total lifesaver. We can now be confident that what we want on the server will be what actually ends up there!

My series on WiX

Irony

Irony is an open source .net language implementation kit. That is, it allows you to create your own custom languages and parse them at run time. That in itself is nothing new, but Irony is the best I’ve used to date. Performance is good enough to make it useful in real-time processing applications too! If you want to allow custom modification of your application’s behaviour it’s the way to go (IMHO). Documentation is a bit thin on the ground so I’ll be running a series of posts on it in the New Year.

Irony on CodePlex

Blogging

This blog has only been running since July but I’ve had a great time writing every post. I thought I’d make my stats public for you:

• 12 posts;
• Averaging around 50 visits a day on weekdays, steadily rising month on month;
• 8000 visits in total;
• Just under 2000 unique visitor, thanks for coming back!
• The vast majority of search traffic comes in through Google. But you knew that already;
• The top two referring keywords were 'wix' and 'IIS'.

Kindle

I’ll admit it, I scorned the kindle. I trotted out all the familiar excuses: ‘Its just not the same’, ‘where’s the book smell?’ etc. The truth is though that this was my best purchase of the year. Since buying it I have been reading more, and reading more often. It lives in my jacket pocket so it’s always there to help my fill a spare ten minutes. I love being able to get the next book in a series instantly when I finish the one before. The amount of books for under £2 is brilliant. Get one. Now.

Amazon kindle

So, there is my 2011. I’ll be back in the New Year with a couple more deployment and WiX posts and I’ll get started on a new Irony series. I hope you have all had a great festive season and that you enjoy your New Year!

Hey, it’s been a while! The usual #lifegetsintheway excuses all apply, but you knew that right? Fear not though, treasured reader, for today we are going to delve into the adrenaline-filled world of MsBuild/TFS interaction!

But Why?

There are plenty of reasons for wanting to interact with your TFS server from MsBuild. Maybe you want to ensure that you always get the latest version of a referenced DLL on each build? You could need to update a source-controlled log file when a certain configuration is built on your continuous integration machine? All of these sorts of things are possible and I’ll be going over some of the more complex scenarios in future articles. For now though I want to fix a bit of an annoyance with the web or service installers I went through in previous posts. If you haven’t worked through these don’t worry, you can get the finished source for the service installer here: WixServiceInstallerExample.zip (184.90kb). (You will need WiX installed, but that is a good thing)

Lets Go

Lets start by recreating the problem; step one is to add the service installer solution to source control and check everything in. Once done, try to build the installer project. Oh no!

Unable to execute transformation. Access to the path ‘……..’ is denied.

What is happening here? The installer build process needs write access to the file WixServiceInstallerExample.wxs, which is denied because it is currently checked in. You can verify this by checking the file out and building again, which will work. So all we need to do is make this automatic.

Open up the project file for the installer (right click > Unload project, right click > Edit WixServiceInstaller.wixproj). Add the following three properties to the top PropertyGroup element:

<TfsExeLocation>$(Vs110ComnTools)..\IDE\tf.exe</TfsExeLocation>
<CheckinComment>Checkin for installer build.</CheckinComment>
<CheckinOverrideReason>Checkin for new installer build.</CheckinOverrideReason>

The first item is the path to the ft.exe file on your computer. Unfortunately we have to do all of this stuff using the command line! The nice thing about defining it here though is that if you have a wacky install on your build box like I had to deal with for one client, causing the TFS build to break, you can override this property in your TFS build definition. If you are using VS2010 then use Vs100ComnTools instead.

The other two items are there for when we check the file back in again, ensuring we don’t get any policy blocks on checkins.

Now, right at the beginning of the BeforeBuild target at the bottom of the file, add this line:

<Exec Command=""$(TfsExeLocation)" checkout %(ProjectReference.Filename).wxs"
               Condition="'%(ProjectReference.ContentProject)'=='True'" />

The Exec command is deliciously powerful; suddenly the power of any command-line tool you can find or build is at your beck and call. There really isn’t a huge amount to this; we pass a ‘checkout’ command and the path to the wxs file to the ef.exe command. Next add the following right at the end of the BeforeBuild target:

<Exec Command=""$(TfsExeLocation)" checkin %(ProjectReference.Filename).wxs
                 /comment:"$(CheckinComment)" /noprompt
                 /override:"$(CheckinOverrideReason)""
        Condition="'%(ProjectReference.ContentProject)'=='True'" />

This time we’re checking the file in. It’s a pretty similar command to the last one but we are just passing a few more arguments specifying comments and policy override reasons to be stored next to the checkin. The noprompt option tells tf.exe not to pop up any dialogs etc.

Check out the show!

That was easy huh? You can go ahead and reload the project now. Make sure all files are checked in and run the build. Keep watching the solution explorer window and you should see the wxs file’s icon changing to checked out, and back to checked in as the build progresses. Happy days.

Limitations

Just bear in mind that this code is always run when you build. That means that even if the wxs file is checked out before you build, it will end up checked in afterwards.

Hopefully this post will have been of use to someone, but I’m off to get started on the Christmas celebrations. Merry Christmas to those of you who celebrate it!