Recently in Programming Category

A feature of changeset metadata in Team Foundation Server 2008 is that it is actually editable.  If you look at the changeset details for a historical check-in in Visual Studio you will notice that the comment and check-in notes fields are enabled and there is a “Save” button. This is by design, but I have known customers that find this fact very surprising. 

In fact people are so surprised that this is even possible that in Teamprise we currently do not provide a way to edit the comment or check-in notes and guess how many customer requests we have had so far to add it?  I’ll give you a clue – it’s less than 1.

Anyway – apart from removing the odd bit of unsavoury language from a frustrated late night check-in, today I found a handy use for updating the comments after the fact.

In TFS 2008 SP1, Microsoft introduced a new feature in the server – to allow branches to be created and committed in a single operation.  This is exposed in the command line using the tf branch /checkin option or through the API using the undocumented VersionControlServer.CreateBranch method.  Creating a branch in this way is very fast because it bypasses the whole requirement to have a workspace created, working folders mapped, a branch to be pended and then the branch finally checked in.  It also uses significantly less server resources to perform which is why the feature got added in the first place.  Microsoft have some very large branches that they manage in TFS :-)

The problem with the current version of the CreateBranch method is that it doesn’t add a comment to the changeset during the branch operation.  But you can, as we now know, add a comment after the fact.  Below is a code snippet to demonstrate this:

public void CreateBranchWithComment(

    string serverUrl,

    string sourcePath,

    string targetPath,

    string comment)

{

    TeamFoundationServer tfs = new TeamFoundationServer(serverUrl);

    VersionControlServer vcServer =

        (VersionControlServer)tfs.GetService(typeof(VersionControlServer));

 

    int changesetId = vcServer.CreateBranch(

        sourcePath,

        targetPath,

        VersionSpec.Latest);

 

    Changeset changeset = vcServer.GetChangeset(changesetId);

    changeset.Comment = comment;

    changeset.Update();

}

Hope that helps somebody.  In TFS 2010 there is an additional overload of the CreateBranch method that allows you to optionally specify many things about the changeset created including a command and check-in notes so this workaround isn’t  necessary there. 

Remember, use your new found changeset comment altering powers for good rather than for pranking your colleagues.

The clever folks over at CodePlex have recently released the code to the sites excellent wiki.  As you would expect from CodePlex team, the code is available as a project on CodePlex at http://wikiplex.codeplex.com.  Even better news is that the code has been released under the permissive MS-PL open source license.

Anyone fancy getting it integrated with Sharepoint?

Last week at TechEd 2009 North America, I had the pleasure of sitting down with Brian Keller to discuss Teamprise past, present and future. If you have Silverlight installed you can watch the interview or you can download the video from the TechEd site.

If bunnies are just a little bit too cute and fluffy for you, then you might be interested in a little side project that reader Terry Humphries just got in touch with me about.  You see Terry had no love for robotic rabbits in the build process – but an electric guitar was something that he and the other developers in his team would pay attention to. So he hooked up a vintage 1990’s Warlock Electric guitar made by B.C.Rich to TFS and let that rock their world.  I thought this was a cool project so asked permission to share his email with you all. If you want to get in touch with Terry, drop me a line and I’ll send your details on to him.

From: Terry Humphries

My name is Terry Humphries and I work for EnGraph Software. I’ve been a developer for over 25 years the last three months at EnGraph. I came here to join a development team that was scaling up from a couple of developers to over 14 folks. Part of my job has been and continues to be leading EnGraph’s push into using Team System. I spend part of my time wearing a developer hat and part wearing the TFS admin, Build Sensei hat.

Having always been a strong believer in nightly builds and making sure everyone is aware of the status of the build, I’m always looking for ways to get the other developers invested in the status of the build.

Having seen Brain aka the Build Bunny and the Lava Lamp build indicator I decided it was time to create something unique for EnGraph to use.

I almost used a full size traffic light, but since all of the pcs here are named after guitar manufacturers, a Build Guitar seemed the way to go, and the search was on. It took me about three week to locate the used Warlock I used as the basis of the project. I didn’t want a run of the mill guitar, it need to be electric and it needed to have a unique look. When I got the Warlock it’s better years were behind it, the body was in bad shape. I had to end up stripping it, filling in a few dings and refinishing it with a purple undercoat and a bronze metallic pearlized overcoat.

I looked at several options for the switching mechanism for the LEDS. Basically, I wanted something that would provide the low dc power needed to drive the LEDS and a programmable interface for switching them on/off. I considered Ethernet based relays, Bluetooth based relays, Ethernet to parallel port converters, and USB controlled relays. Mostly because the other options were much more costly I settled on the USB controlled relay. I decided to mount this control circuit in its own box and use standard Ethernet cabling to get the power to the guitar from the relay. With this option the only things I had to mount in the guitar were the LEDs, the Ethernet jack, and wire connecting them.

Once I obtained everything I need I started build the controller. Wanting it to also be somewhat different I decided to mount the relay circuit old 3.5 diskette plastic case that was designed to hold 10 diskettes. After mounting the circuit board I added the ethernet jack and connected the power supply. Cut a few hole for the cables and bam the Build Guitar Controller was born.

Next, guitar time. I decided the best place to mount the LEDs was in one of the pickup coil frames, you see a Warlock comes with 2 Humbucker pickup coils each mounted in its own frame. I fashioned a piece of black plastic to fit the frame and drilled three holes for the LEDS. Then I wired the LEDS to the Ethernet jack I had placed in the jackplate.

Then I hooked everything up loaded the Phidgets drivers and using they’re control panel applet tested the wiring and after a few minutes I had everything working as planned.

The folks at Phidgets provide 2 way to interface with their devices, either directly or via a webservice, I used both. I couldn’t find a TFS event that fires when a build starts so I created a custom task that turned on the correct relay and hooked it into our build scripts via the BeforeEndToEndIteration target and then used Howard van Rooijen TFS Event Framework to react to the BuildCompletionEndpoint to set the red and green leds.

The basic code for manipulating the relays is only 9 lines:

InterfaceKit RelayPhidget = new InterfaceKit();

RelayPhidget.open("gibson", 5001);

System.Threading.Thread.Sleep(1000); //wait for the server to connect

RelayPhidget.outputs[0] = false;     //Set build start off

RelayPhidget.outputs[1] = true;      //Set build success on

RelayPhidget.outputs[2] = false;     //Set the other off

RelayPhidget.outputs[3] = false;

RelayPhidget.close();

RelayPhidget = null;

I’m not sure what else I can tell you about it other that it’s a big hit with the other developers. As for more about EnGraph you can visit our web site at www.engraph.com

Hardware:

• Warlock Electric guitar made by B.C.Rich vintage 1990s
• 10MM diffused LEDS in Blue, green and red
• Phidget Interface Kit 0/0/4 available here
• 5VDC 350milliamp wallwort power supply
• Various bit of wire, tape glue paint, etc.

Software:

• Team Foundation Server Notification Event project template from Howard van Rooijen
• VS2008
• Phidgets Driver

Thanks for sharing this with me Terry, and for allowing me to post your email.  For anyone interested, I’ll be talking more about integrating with Team Foundation Build API’s during my session at Tech·Ed North America 2009 next week.

DTL307 Brian the Build Bunny: Extending Team Foundation Server Build

Fri 5/15 | 9:00 AM-10:15 AM | Room 404

This session digs deep into customization of the Microsoft Visual Studio Team System Team Foundation Server Build system. Learn about the .NET API for Team Foundation Build and how to use it to create your own build status display or even have your team chastised about build failures by a robotic rabbit.

My friend and fellow Team System MVP, Neno Loje, has been on a blogging frenzy this year. Recently he has published a handy Visual Studio template if you do a lot of playing with Team Foundation Server API calls (as I do), or if you are trying to play with an TFS API example that you have found on the net but are having trouble finding the assemblies required to use it.

Go check out Neno’s post now if you are serious about TFS API development, and while you are at it be sure to subscribe to his blog.

After the highly successful Developer Developer Developer event in Galway last year, this time it is moving north to my neck of the woods – Belfast. For those not familiar with the DDD events they are run on a Saturday and everyone gets together in this great free event run for the community, by the community.  Session submissions are an open process – and session can be submitted by anyone and the sessions that are held are the ones with most community interest.

There are no Microsoft speakers present, just speakers from the .NET developer community – although I hear on the grapevine that our local Irish DPE’s will be hanging around the crowd to soak up the atmosphere and chat to people that want to the idea behind the get together is that we all get to share in our real world experiences and knowledge from working down at the code face.

Best of all the event is FREE, with all the speakers volunteering and facilities kindly provided by the sponsors.  Not only can you learn about some of the technologies that you would have to pay to go learn about at a TechEd or PDC - the DDD events are a really great way of meeting interested and interesting people locally and making some great contacts.

So – if you are around the area then I encourage you to join me on April 4th in Belfast.  If you fancy giving a talk then head over to the site quick and submit your talk idea now.  Alternatively, if there is a topic that you would love to see covered then suggest it on the site.

Find out more at: http://developerdeveloperdeveloper.com/belfast/

Earlier in the week I was on a support call with a customer who was seeing strange issues.  It later transpired that they had a TFS workspace configuration issue that we were not able to solve quickly over email.  When we were saying the words “TFS Workspace”, they had been translating this as “Working Folder Mapping” which is a perfectly sensible thing to do for someone new to TFS – but was sadly not helping in this case.  Once we’d ran the user through a couple of scenarios they instantly “got it”.

One of the many pleasures of working for Teamprise is that our end users are nearly all developers which makes our life much easier.  In this particular case, once the customer “got it”, they quickly forgot the time when they hadn’t and became a little apologetic blaming “User Error” for their troubles.

I don’t believe in “User Error”.  I’m not just being cute – I really don’t believe that it exists.  If you went up to a vending machine and instead of a tasty beverage you ended up with a nasty cut you wouldn’t say it was “User Error”.  Equally, when getting into an elevator to ride from the 20th to the 22nd floor, if you had to travel down 20 floors before going up to your destination it isn’t “User Error” that is causing the diversion but an issue with the user interface and the design of the application.  Especially if you go on this diversion more than twice.

Admittedly, there are times when users accidentally do dumb things – and there is a learning curve to all applications (the fun my son is currently having learning his numbers by pressing the buttons in elevators is an example of that learning curve).  However if more than one person is having the same issue with your application then it is a good sign that you have a usability fault and you need to make your application more transparent.  While some usability issues will probably always have to live in your software (especially if it is not a mass-market consumer application) at least try to file down some of those sharp edges in your code.  That way, if they do go off the beaten track then at least they shouldn’t get hurt.