Back in October I submitted a bug to Connect regarding the Process Editor and the fact that it makes background changes to the WIT xml files without notifying the user. Yesterday Microsoft posted a reply that this will be fixed in the next version of TFS Power Tools. When the next version will be released is not known, but February and Q1 2011 has been mentioned. I can’t wait, it is going to save me some serious headaches when editing work items!
Tag: 2010
Areas and Iterations
I’ve built a couple of custom reports for a client, and in doing so I’ve been forced to dive deep into the TFS 2010 database, which sometimes leads to interesting findings.
This time I found a strange approach to Areas and Iterations. For all work items areas and iterations are stored in the table xxTree. But then there are two other tables named tbl_Areas and tbl_Iterations, and they also contain all areas and iterations. But without all the other stuff found in xxTree. Now, one might be tempted to believe that these tables are somehow connected and perhaps contain a foreign key pointing to the xxTree table. But no… As far as I can tell, xxTree is for work items while tbl_Areas and tbl_Iterations is used by MTM2010 for mapping test plans to areas and iterations.
So for anyone writing queries using these tables, make sure you use the right ones or you will end up with some very strange results.
Misleading error message when setting up TFS Warehouse
Encountered a stupid error message yesterday. Had a TFS 2010 instance where reporting services had been disabled. When trying to enable it again we got an error message saying “Object reference not set to an instance of an object”. SQL instance was correct, database names (Tfs_Warehouse and Tfs_Analysis) were correct and I had a valid username and password for the TFSService account. However, as the original installation was done properly, using the TFSReports account for reporting services, we got this error message when trying to re-enable reporting services.
Now, even though the error was “correct”, I would have appreciated an error message that was a little bit more informative…
ASP.Net vulnerability affects TFS
All versions of TFS are affected by the ASP.net security vulnerability discovered recently. Brian Harry has blogged about this and attached a document on how to work around this problem until a patch is released. If you are a TFS admin you have some work to do…
Work Item Link Filters
Interesting fact regarding work item link filters when working with the Process Editor to create a new process template:
“Include all” does not equal “Include” + selecting all link types.
- “Include all”: link types from all installed process templates will be shown to the users.
- “Include” + check all boxes: Only the links types in the current process template will be shown to the user.
In my experience, “Include all” is never a good option for a work item link filter. It will only serve to confuse users and break reports. But when working with the Process Editor “Include” restricts your selection of link types to only include those specified in you process template. If you want to use link types from your template and some of the system defined link types (like parent/child) you will have to edit the XML markup manually.
TFS Backup Plan
Brian Harry recently blogged about a cool new feature in the next version of TFS Power Tools (no date yet). Backing up and Restoring your TFS Server is the most exhaustive post and makes for some interesting readin while Backing up your TFS Server with Sharepoint and Reporting more or less just states that you can backup the Sharepoint and Reporting parts of TFS as well.
Now, lets hope they add a tool for restoring the backups as well 
Messing up TFS with LinkControls and Fields
I recently stumbled across a interesting case using TFS 2010 where you could end up unintentionally setting a field on a work item that is not supposed to use the field at all. This is probably best explaned with a simple example.
Lets say you team project is based on the MSF for Agile v5 template. You want to modify the Task WIT so that the LinkControl in the Links tab includes a column for severity. This way, whenever a Task is linked to a Bug you will know the severity of the bug without opening it up. Perfect! Lets do it!
I’ll skip the details of how to do this, the interesting part is that even though Task does not use the field Severity you will need to add it to the Task WIT in order to show it as a column in the LinkContol. Name, Field type and Ref name must be identical to what is used in the Bug WIT. And this is where you might make a small but potentially very annoying mistake. If you also copy the rules of this field from the Bug WIT (easily done if you copy/paste between XML-files or if you are just very thorough and decide to specify the field exactly as it is on the Bug WIT) all your Tasks will from now on be asigned the severity level “3 – medium”.
And why is this bad? Well, you’ll probably not notice it for some time. If you are lucky you wont ever notice it and if so, good for you! But chances are that sooner or later someone will get a very wierd result from a work item query or report. Lets say you have a report that counts the number of bugs of each severity level. Depending on the laziness of the person who designed the report, it might not check the work item type because only bugs used to have a severity level… and now this report is telling you that the number of bugs of severity level “3 – medium” is increasing at an alarming rate!
Good news is this that the mistake is fairly easy to solve. Remove all rules for the severity field on the Task WIT, create a query to return all tasks with severity “3 – medium”, export to excel, remove severity value from all tasks and publish the changes back to TFS. Done! Unless your report keeps track of history as well…
Another reason for moving to TFS 2010
Recently one of my clients (who uses TFS 2008) encountered the TF14083 warning when merging two branches. This is the warning message:
The item ‘{0}’ has a pending merge from the current merge operation, please resolve and check in the current merge and merge again to pick up this change.
In most cases this is nothing to worry about, all you need to do is just what it says in the message. Resolve, check in and merge again.
But a cautious user might start to think along the lines of “so,what happens if the second merge fails? I’ve already checked in the first part of the merge!”. The simple answer would be that you do a rollback to the previous changeset using TFS 2008 Power Tools.
However, in TFS 2008 the rollback will only rollback the actual changes but the merge history will not be affected and this will cause trouble when you try to redo the merge operation as TFS believes the two branches have already been merged. You can probably solve this dilemma by doing the merge using TFS command line tool and use the /force option but by now most people are thinking something along the lines of “this is stupid, TFS should be able to handle all this”.
And if you move to TFS 2010 it can! Not only has one of the main reasons for the error above been fixed, but rollback is now part of the standard TFS command line tools and has an option for keeping merge history or not. There, another good reason why you should move to TFS 2010! 
jesfer 