I’ve been dabbling with TFS event handlers and check-in policies recently – which came about because I had a meeting with a Team Explorer Everywhere (TEE) user a few days ago and he mentioned that one of the things he’d like to see is the ability to include references to work items in the check-in comments. Why? If you know the work item id(s) you’re working on then finding them via a query in the pending changes view requires you to click to another tab, possibly change query, and then click each work item. If you could just put the work item ids in the comments then it would improve the flow at check-in. Something like “Fixed bug ”.
The more I thought about it the more I liked the idea, and my first reaction was that a custom check-in policy could provide a solution, by parsing the check-in comment for work item ids and then linking them to the changeset for the pending check-in. So, I started to write a check-in policy, first parsing for work items, then trying to link them to the changeset. After a while I came to the conclusion that I couldn’t access the changeset on the client side, or at least I couldn’t (and still can’t) find a way to access it. (If that’s wrong then please let me know).
Searching around I came across this extremely useful blog by Jakob Ehn at Inmeta. That post helped confirm my suspicions about client side access and paved the way to developing an event handler to achieve my intended solution. I took a look at Jakob’s merging event handler and that helped me a lot.
So, what I’ve ended up writing is a server side check-in event handler for TFS 2010 that parses the check-in comment looking for work item ids identified by square brackets:
In this case these three (it could be any number) work items will be validated (do these work items exist, do you have access to them) and then linked to the changeset for the check-in:
The event handler was actually fairly straight forward to write, once I had an example to work with. There are some good advantages to using an event handler:
- Straightforward implementation (subject to whatever logic you want to invoke), including debugging.
- Easy deployment. Add the .dlls to the TFS Application Tier plugin directory (in my case C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\bin\Plugins). TFS even notices file changes in this folder and recycles the application pool to pick up the changes. Note that this does mean that there is a short period when TFS is not available (about 10 secs on my machine).
- No impact on the clients – the event handler works without any changes being made to development machines, and also works immediately for both Visual Studio and Team Explorer Everywhere clients.
I found this an interesting problem to solve and I hope useful to others as well so I thought I’d share my code and binaries in the EmbeddedWorkItems codeplex project.
You can download or view the source and the binaries for the event handler. I also added in both a Visual Studio and a Team Explorer Everywhere check-in policy that provides some client side validation to ensure that valid work items are in the comment. These check-in policies are not required, but as the event handler will silently ignore invalid work item ids I thought it might be useful to be able to validate the work item ids before they get submitted.
So; there’s a C# event handler, a C# check-in policy and a Java check-in policy for you to view, use or extend and improve via codeplex. I’m sure there’s plenty of room for improvement in my implementation , and it’s the first time I’ve used the recently released Java TFS SDK (and it was a positive experience, the samples and documentation really helping me with the Java check-in policy).
I hope that either the event handler or policies are of use to you, or that the source has some value if you are considering your own customisation of TFS. It’s reconfirmed for me that I can add to or change the functionality of TFS relatively easily, and across both Visual Studio and Eclipse clients.