Work item blow-up when editing Team Foundation Queries in Excel

I have just completed a manual rollback on loads of work items due to a unexcepted feature in Excel. Be warned: do not try this on work items in progress!

This is the receipe
1. Open a WIT query in Excel

2.  Now go to a line in the top of the query region sheet.


3. Select row (Shift + Space) and copy (ctrl + C)
4.And now maks a big mess of all your work items by pasting this line as a new row (CTRL + +):

As you can see, the content of my work items has now been shifted down one row, except the ID column!

I have now effectively rewritten all my work items, that goes for content and all relations!

And, no, I did not see this until i had published my changes...

Together with two of my colleague’s we spent 4 hours straight to correct every WIT back to original state. We had to use the WIT history log to revert any changes. It was a big mess, so I warn you people BE very careful when editing your backlog items using Excel.

Inmeta Build Explorer

• We have just released an 0.9 version of the Team Explorer build browser. You can download it at

visualstudiogallery.

A customer of us (DnBNor) wanted to display builds in a tree view and we agree: a large collection of builds is hard to navigate in a flat list.

The hierarchy is defined by splitting the build definition names by a token (default:  '.' ). This token can be changed in the options dialog (context menu on root folder).

This is what the Inmeta Builds Explorer looks like when expanded.

  

The context menu on the leaf nodes has the following commands:




Playing around in the vsct file was an experience, but thanks to the VSCT Powertool i very soon got some kind of understanding of the guids, ids, symbolic names, bitmaps and what not. Well, at least i got my menus working. BTW: if you ever should end up developing a Visual Studio Addin, please remember to delete the previous debug version of the extension every time you change the visual studio command table file (vsct). If not, your changes will not be detected.

We wanted this implementation to be short and sweet, so the idea was to create simple placeholder UI nodes which redirected all commands to the actual Build definition node. Very simple, yet efficient. This design decision does have some consequences:

• 
  The tree nodes are not generated until the user click on the root node. The reason is simple: All Team Explorer plugins are loaded async and since we are dependent on the actual UI node in the original build list, timing issues where imminent. So we do not regenerate the tree on Refresh/load: we wait.
  
• 
  
  The existing Build plugin does not reveal a lot of interfaces, thus I had to revert reflection to invoke the correct method in the original build UI node, when executing context menu commands.
• 
  
  I tried to use the existing public interfaces to search for the build UI nodes using the CanonicalName, but with no success. We therefore use reflection to get hold of the corresponding build UI node. 
  
  
• If you select 'Edit build definition' from the Inmeta Builds Explorer and then save, the selected item will jump back to the original Build definition node.