Search in Tfs Work Items never was so easy :)

The search box functionality was introduced with the August release, but I see that some people still does not know it. This question arose during a talk about how to handle the lifecycle of a bug, and when it was time to deal with the “avoid duplication” issue, people told me that they want a simple way to search work item by text, because this is the fastest way to verify if a bug has some duplicate.

Basically the needs you have during search for duplicates is to be able to do a free text search inside title and description to Work Item and a quick way to create duplicate candidate lists, that you need to share with testers and others to verify that they really are duplicates.

The search feature was present in the web interface since the first RTM of TFS 2010, but it is quite often overlooked, because not every person uses the web interface. All you need to do is browse to your Web Interface page (ex. http://localhost:8080/tfs/web/I) you can notice a nice TextBox to search in Work Items.


Figure 1: Search functionality inside the Team Web Access application

But if you have latest power tools installed, you can search directly from Visual Studio, just be sure that you are visualizing the Work Item Tracking toolbar and you should see a nice texbox where you can simply type something and press enter to search.


Figure 2: The new free text search textbox added with TFS Power Tools

Clearly this is really easier and faster than using the web interface. In the December 2011 update you  can use to open a Work Item by Id, simply press the Id and press enter and Visual Studio immediately opens the corresponding work item.


Figure 3: Just type the id and press enter to edit a work item if you know the id.

Do not forget that you can always Right-Click the Work Item and choose “Copy Work Item Shortcut”, this is an extremely useful function if you want to give people not used to Visual Studio the ability to quick edit a work item, just give them the link, and if they have permission, they can view/edit the WO directly from the web.


Figure 4: A link to a work item is a Url that points to the edit view of the Work Item.

This functionality is useful during bug duplication to quick build a series of possible duplicate bug list that is usable from every person in the team that has access to the Web. If you look at the documentation of the Work Item Search Functionality, you can notice that you can even specify complex filter, like “cart T=Bug” that basically search the term cart only in work item Type = Bug.


Figure 5: You can issue complex query to the work item search.

Now suppose the search returns a bunch of Bugs, you can select those one that you believe are duplicates, and then simply Right-Click and choose to “copy Work Item Shortcut” to quick create a list of duplicates, or you can open all those Work Item in project or Excel, or send to Outlook because maybe you need to email to the test team, asking them if that group of Bug are really duplicated.


Figure 6: You can create a mail with a single click that contains all selected Work Items.

You can see that the Ids are clickable and as you can suspect, each link opens the related work item in the Team Web Access web site. Armed with all these possibilities, searching and reviewing list of possible duplicated bug is really easier.

Gian Maria.

Team Foundation Server power tools December release

You can read all the details Here, but basically it is a release mainly focused for “non visual studio developers”. This new release has a MSSCCI provider for 64 bit, and a version of Power Tools for eclipse, and it is available from the Eclipse update site.

For those ones interested in knowing the news for VS Power Tools, basically it add the capability to search for number in the “Work Item Search Box” and a bunch of rules in the Best Practice Analyzer to identify issues with Project Server interaction, so, for Visual Studio Users it is a minor release, and probably the last for Visual Studio 2010, as stated by Brian

Right now, I’m thinking this will be the last Power Tools release for the VS 2010 wave of products.  After the new year, we are going to turn our attention to getting all of the Power Tools working seamlessly with VS/TFS 11 (and removing all the ones that have now been added to the product

Happy TFS.

Gian Maria.

TFS Pills: merging conflicts during unshelve.

Shelvesets are a really useful concept in TFS, and you should be aware that thanks to Power Tools you can even do a Merge during an Unshelve in case of conflicts. As an example suppose this simple and stupid scenario, you have this code.


Figure 1: Original Code

Now lets generate a conflict with Shelveset; simply typing some text.


Figure 2: Modified code, insertion of a simple comment.

I’ve simply typed some comment into the class, now Shelve the file without preserving pending changes, the file reverts to the code in Figure 1, now modify again the comment of the class as shown in Figure 3       

Figure 3: Another modification done to the class, this modification conflicts with the version in Figure 2.

Now check-in and commit this code (this simulates the situation when you need to suspend with shelve the work you are doing to accomplish higher priority task), then unshelve the previous shelveset, as you can verify the code revert to that one shown in Figure 2, and you lose the modification of the last check-in. This happens because the unshelve operation does not trigger a merge in case of conflicts. If you looks at the output windows you should find a message telling you that a newer version exists in source control as shown in Figure 4


Figure 4: A warning by the source control, a newer version of the file exists.

Now you should simply reissue a Get Latest command and TFS will present you a list of all conflicts that originates from the unshelving operation.


Figure 5: Issuing a Get Latest will trigger the conflict windows that shows each file that conflicted after the unshelve operation.

This is a situation where you have a simple conflict when a file that got in the shelveset was modified and checked-in after the shelve operation, you can merge with the tool of choiche, accept both the comment and check-in, to proceed to the next example. The situation of the file is now represented in Figure 6 and this is the starting point of another example of merging shelvesets when a conflict happen between two users


Figure 6: Both comment where accepted during the merge.

Another type of conflict arise from unshelving conflicting code from another developer. Suppose Dev A and Dev B start both from the code in figure 6, Dev A types a third line of comment telling “third comment lineand shelve the code. At the very same time Dev B does a conflicting modification, typing a third line of code that states “conflicting third comment line” and after this modification, she receives a call from Dev A that asks to review his shelveset. If Dev B try to unshelve the shelveset from Dev A she got the error in Figure 7


Figure 7: It is not possible to unshelve because of conflicts.

This happens because the standard unshelve operation does not permits to handle conflicts, if Visual Studio unshelve a conflicting file from Dev A, all the modification pending from Dev B will be lost. This is an annoying situation that you can solve with Power Tools.

If Dev B want to merge the code in the shelve of Dev A with her current code, she should open a Visual Studio Command prompt, move to the workspace where the project resides, then issue a tfpt.exe unshelve command directly from command line. The command line utility will open the same UI to unshelve that you got in Visual Studio, but now, when she browse to the shelvesets of Dev A and try to unshelve, she got a nice windows that shows all conflicts.


Figure 8: Tfpt.exe unshelve presents you a list of all conflicts that occurred during the unshelve operation

Now you can try automerge, and if it fails, you can press the “Resolve” button (or you can directly go for the “resolve” button without try automerge if you do not like to automerge conflicts 🙂


Figure 9: Resolve conflict during unshelve.

In Figure 9 you can see how to ask for a manual merge. Pressing OK Will open the standard tool for merging, you can now do a manual merge and save the result of the merging. Taaadaaaa, thanks to Power Tools you are able to unshelve conflicting shelvesets made by other developers.

Now what happens if Dev B want to revert to the original code she has before merging with the shelveset of Dev A? No problem, because the tfpt.exe unshelve command had created a backup shelveset with all the pending changes just before the merging operation, so if you want to dischard all the modification and revert to the same code that you have prior of the unshelve operation, you can issue another tfpt.exe unshelve operation, choose the backup shelveset (it has the same name of the unshelved shelveset with the string _backup appended), and when the Resolve Unshelve Conflict windows appears (Figure 9) you can simply choose to undo my local changes and take the shelved changes, and you are done.

Happy shelving.

Gian Maria.

Distributing Visual Studio addin for the team

One of the most requested feature for TFS is the ability to distribute automatically Visual Studio adding to team member. This needs is especially important for addin like Custom Check-in policies, because if developers do not install check-in policies they would not be run during a Check-in. Every time you show check-in policies to a customer, it immediately ask you how to distribute them to all developers pc automatically.

I found that some people are not aware that such a feature is already there, but is included in TFS power tools, so it is not available out of the box with a plain installation of Visual Studio and TFS. After installing power tools you can simply right click in the Team Members node and choose Personal Settings


From there you can see all the options for the collaboration features and one interesting option is called “Install downloaded custom components…. but how it works?


This extension verifies in the source control the presence of a path called $projectname/TeamProjectConfig/CheckinPolicies and inside that folder looks for 1.0 2.0 or 3.0 folders for VS2005 VS2008 and VS2010 addins respectively. Every dll found on that directory is automatically downloaded to the right location and made available to client computers. This is an example picture taken from the help of Power tools that shows how to include the dll of the custom checkin policies of Power tools with the right name to be available for every team member (this is needed to made upgrade to the policies without reinstalling powertools to each client machine as example)


You can include also dll containing Custom Control for Work Item editing, they should be included in a folder called $projectname/TeamProjectConfig/CustomControls.