You’ll need the TFS Power Tools to do it the way I’m describing it (that’s the easiest way) – hopefully I’ll get around to adding screenshots later on.

Select the work item you want to edit and go to the Workflow tab. Select the state (outlined in red) and do the following:

1. Right-click and select Open Details
2. Add the Ref Name for the field you want to make required for the selected state
3. Open this row and select the Rules tab
4. Add the WHEN condition (this is the part that just isn’t intuitive)
5. Set the field (maybe System.Reason since that’s tied to the state change)  and set the value the field needs to be in order for the field you want to be required to be required (read it slowly – it’s confusing)
6. On the Rules tab add the Required condition (don’t need to fill in the For or Not values)

Enjoy.

And thanks to Mike Azocar, Team System MVP and overall good guy for the first external FUQ!

1. In general, Microsoft exams do not test your knowledge of the UI. Thus studying up on what menu items are available is generally a waste of time.
2. Understand the command line. Partially because of 1), but also because the questions can be written more clearly, there is a tendency to lean on the command line for answers. You don’t need to be a command line genius, but you do need to understand the basics and understand the features available.
3. Don’t believe that you can pass the test simply because you are an expert TFS user. The test is a Technical Specialist exam, which means that it does not test you on best practice type questions, but rather on questions that test your ability to perform particular tasks related to administering TFS and Team Projects.
4. The answers for the test are specific to TFS 2005 SP1. That means that you will need to study up on some features which are available only in SP1, such as custom controls and the like.
5. When the question says only 2 answers are correct, and you think 3 are correct, think very, very carefully. You are wrong, and there is a something you’re missing.* (see Disclosure 2 below)

Study materials:

• You can’t go wrong with Pro Visual Studio Team System with Team Edition for Database Professionals by Jeff Levinson and David Nelson.
• Consider buying an exam prep. The test is difficult, and an exam prep may help you learn those rather obscure points you’ll need to be proficient at to pass the exam.

Full Disclosure:

1. Jeff Levinson is a coworker. But my recommendation of his book is based on the large trove of useful information contained inside of it.
2. I was involved in the creation and technical review of 70-150. Thus, I’m bound by NDA to not disclose particular features of the test, or things that other people may be able to talk about. (So, if you’ve successfully passed this test, feel free to comment on this post, and let others know your recommendations!) PS. If you have complaints about the test, I’m not WHOLLY responsible…

Thanks to Steve Shippee for recommending this FUQ!

UPDATE:  Don’t forget to register for a free Second Shot, just in case you fail the exam the first time!

1. Use Howard van Rooijen’s VS2005 template. Basically Howard’s put together a Visual Studio 2005 project template that allows you to create a new web site that’s already set up to listen to all of the important TFS events. It currently handles the following events (which are all of the ones that are not deprecated as of VS2005 SP1):

• AclChangedEvent
• Branchmovedevent
• BuildCompletionEvent
• BuildStatusChangeEvent
• CommonStructureChangedEvent
• DataChangedEvent
• IdentityChangedEvent
• IdentityCreatedEvent
• IdentityDeletedEvent
• MembershipChangedEvent
• WorkItemChangedEvent

It not only creates the appropriate SOAP endpoing, but also creates the necessary XML Schema so you can deserialize the event data into an object that you can work with directly. Very, very nice. I’ve used it several times, and recommend it highly. (Does anyone know if there’s a VS2008 version out there yet? Howard?)

2. Use the TFS Event Handler hosted on CodePlex. I haven’t used this tool yet, but it looks useful. Basically, you don’t use it to write your own event handler, rather you allow it to catch all the events from TFS and send them to you using an MSMQ channel (created in WCF). It looks very promising! The project is managed by Martin Hinshelwood (blog), and has an initial release available.  (Update: Martin Hinshelwood notes in the comments that he borrowed the objecs from Martin.  That makes these two tools related!  Thanks for all your hard work, both of you!)

Leave a comment if you’ve used either of these tools!

Here’s why you really want so many build scripts. The Visual Studio Team System (VSTS) and Team Foundation Server (TFS) system tracks build information according to build name and build run. Thus, if you execute a build called “My CI Build” twice, Team Build will record data about each build, and will categorize the build information according to the build name. The Team Build report gives you data about each build, and, most importantly, the difference between this build and the last successful build of the same name. This means, that in the “My CI Build” example, the second build report would show the difference between it and the first build. Bottom line: you can tell exactly what check-ins occurred and what work items were worked on BETWEEN the first and the second “My CI Build” build. (This is true even if there were other builds run by the server, as long as they have different names.) Thus, I can see, at a glance, EXACTLY what transpired between the two builds. And if the build is broken, I can find the offending code extremely rapidly! I can also report to anyone who needs the data, exactly what was accomplished!

So, here are a few recommendations around the builds scripts you’ll need:

• Continuous Integration (CI) build script – This script runs every time someone checks in code (with certain restrictions). Since you likely won’t want an aggregate report on these builds, you can actually modify the build to not archive the build status in the TFS Warehouse.
• Daily / Nightly build script – This build runs every night at a set time. This build shows you what was accomplished during that entire day, including quality metrics, code churn, etc. This is one of the most valuable builds, since its reporting is clearly segmented by time — one build per day. This allows a team to see what is being accomplished on a day to day basis. Very useful for reporting quality changes inside of an iteration.
• Weekly build script – This build runs every weekend. Like the daily build, it will allow the reporting engine to show you what was accomplished that week, and how quality changes from week to week. This allows you to see aggregate changes over a chunkier time sequence, namely weeks. Very useful for reporting quality changes over several iterations, according to time.
• End-of-iteration build script – This build runs at the end of every iteration. This gives you metrics on what was accomplished during the entire iteration.
• Release to production build script – This build is run after the code has been released to production. Note that you do NOT run this build to CREATE the executables for deployment, but run this simply to generate the metrics around what work was accomplished during this release. (Note: always release the executables that have gone through the testing process to production. Do not recompile the ’same’ code and push directly to production. It’s too dangerous.)
• On-demand build script – This one is used for folks who just need to trigger a build whenever. Unless it’s necessary or useful, you may choose to have this build not report anything back to the data warehouse.

So, how do you create all of these builds? It sounds like lots of work, but it’s not. Because these builds are being used primarily for reporting, they are all going to be nearly identical. (You may choose to have some of them not report their data to the warehouse, but that’s about it!) So, all you do is create the first build (the hard part), and copy it several times, giving it a different name each time. That’s all there is to it! (If you feel you’ll be making changes to the build, you may also want to consider branching the TFSBuild.proj file directly in place. This allows you to merge changes between your builds.)

The Team Foundation Server Event Subscription Tool on Codeplex is one of the better tools. It not only has a UI for generating the filters, but it allows you to unsubscribe as well. Props to Jeff Atwood (of Coding Horror fame) and Michael Ruminer for updating this tool. And thanks to the hard work by Naren for creating the first pass at the tool. (I used to recommend Naren’s version, but this one supersedes his excellent work.)

(But for those of you who want the command line pain… Here’s the link to creating filters for BisSubscribe.exe manually.)

Please note that this will not work in Visual Studio 2008 (Orcas) and beyond.

Update:  As Steve Shippee mentions in the comments, this will NOT recover your documents stored in SharePoint!  It only recovers those documents stored in version control.  (Which brings up a practice I believe is good — backing up your SharePoint documents to TFS Version Control at the end of every iteration.  But that’s for another blog post.)

Thanks, Steve, for that vital point!!!!