Test Attachment Cleaner

Recently we started noticing that out TFS database started growing rapidly (nearly 100 GB per month). On further investigation we found that the tests that were executed as part of a CI build had some big files that were being uploaded to TFS.

Grant Holliday has a good blog on using the test attachment cleaner to remove these big attachments – http://blogs.msdn.com/b/granth/archive/2011/02/12/tfs2010-test-attachment-cleaner-and-why-you-should-be-using-it.aspx

We used the tool to clean up a lot of database space. For preventing further growth of the database we also installed the hotfix (http://support.microsoft.com/kb/2608743) on all our build boxes.

Diagnosing subscription and email failures in TFS 2010

TFS alerts that are sent to web services provided us with an option to extend TFS for out business needs. I created a web service and set up an alert in TFS to call my web service. However the web service was not getting any alerts. On doing some online searching, I found two very useful blogs that helped me to debug the TFS alerts issue -

Grant Holliday’s blog on SOAP subscriptions – http://blogs.msdn.com/b/granth/archive/2009/10/28/tfs2010-diagnosing-email-and-soap-subscription-failures.aspx and Chris Sidi’s blog on the Job Agent overview – http://blogs.msdn.com/b/chrisid/archive/2010/02/15/introducing-the-tfs-background-job-agent-and-service.aspx

Following their advice I was quickly able to determine the cause of the alerts not “reaching” my web service and fix the issue.

I also created a power shell script for changing the logging value

# Load client assembly.

[Reflection.Assembly]::Load(“Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”);

 

# Set the TFS URL

$collectionBaseUrl = “http://myServerName:8080/tfs/myCollection/”;

 

# Connect to TFS Server

$tfs = [Microsoft.TeamFoundation.Client.TeamFoundationServerFactory]::GetServer($collectionBaseUrl);

$collectionHive = $tfs.GetService([Microsoft.TeamFoundation.Framework.Client.ITeamFoundationRegistry]);

 

# Get the logging level setting stored the collection hive.

$collectionHive.GetValue(“/Service/Integration/Settings/NotificationJobLogLevel”);

 

# Set the logging level setting in the collection hive.

$collectionHive.SetValue(“/Service/Integration/Settings/NotificationJobLogLevel”, “2″);

Determine the URL of a Work Item from Visual Studio/Eclipse

Many times users may want to send a URL of a work item, rather than the work item number, to another person. The recipient can then just click the link to view the work item details on the browser – something non-technical users would prefer to opening an IDE (Visual Studio or eclipse). There are two simple ways to achieve this – via outlook or by retrieving the URL for the work item.

Send the work item summary via Outlook (only from Visual Studio)

If you have Visual Studio you can select the work item and right click on it. You will notice the an option called “Send Selection to Microsoft Outlook” in the menu that pops up. Click on that option and a new email window will be created with the work item details inserted into the email body.

Get the URL of the work item

If you do not have Microsoft Outlook, you can still get the URL link (from the IDE). Both options are shown below -

Visual Studio

If you are using Visual Studio, you will need to install “Microsoft Team Foundation Server Power Tools”. Once you have installed the same, you can right click on a work item and select “Copy Work Item Shortcut”. This will copy the URL to clipboard and then you can paste it a email/document and send it over to another user.

Eclipse

If you are using eclipse (with the Team Foundation Sever plugin installed) you can also get the URL for the Work item. From the list of work items (obtained using a query), right click the one’s whose link you want. From the menu that shows up select “Copy Work Item to Clipboard”. You now have a link to the work item that you can send to anther user.

Alternatively you can also open the work item in a browser and then copy the URL from the address bar.

Error opening TFS work items in Excel

Recently we came across an issue where a user could not open a work item in excel (using the “Open Work Item in Microsoft Excel” button in Visual Studio 2010). After a delay they are prompted with an error like the one below…

The user had the integration working fine till sometime back and suddenly one day this error popped up. The “Team” tab was also missing in Excel’s ribbon bar. It turns out that the TFS add-in for excel was disabled and had to be reactivated.

The following steps were followed to resolve the issue –

1. Open the “Excel Options” dialog by clicking on the office logo on the top left hand corner and then click on the “Excel" Option” button on the menu that pops up.
2. If everything is working fine, you should see the “Team Foundation Add-in” name appear in the “Active Application Add-ins” or the “Inactive Application Add-ins” section. The reason the add-in shows up in the “Inactive Application Add-ins” section is because the “Team” tab was not click to activate the add-in.
3. If “Team Foundation Add-in” shows up in the “Disabled Applications Add-in” section, then from the drop down (next to the ‘Manage’ label in the screen shot above) select “Disabled Items” option and click on the “Go” button.
4. In the “Disabled Items” dialog that appears, select the TFS add-in and then click the “enable’” button.
5. You can also load (or enable) the add-in by selecting the “COM Add-ins” drop down option (as shown in the screenshot above) and clicking the “Go” button.
6. Verify that the “Team Foundation Add-In” shows up and is pointing to the correct path. If not click on the “Add” button to add the plugin.
7. Check the check box next to the add-in. Click the “Ok” button to close the dialog and you should be able to see the “Team” tab in excel.

Unable to retrieve latest artifact from SonaType Nexus (using Apache IVY)

We recently started using the open source SonaType Nexus repository manager to for our JAVA based projects. In addition to the manager, we utilize Apache IVY to manage dependencies.

Recently we started noticing issues, where Ivy would not get the latest version of an artifact from the repository. To add to the confusion it seemed like some projects (in the repository) returned the latest, where as some did not.

On further investigation it seemed like the maven metadata file (maven-metadata.xml) for the group was not being updated every-time Ivy was used to publish an artifact. It was ONLY updated when a artifact was manually uploaded to the repository (using the GUI interface), which resulted in the “latest” artifact being retrieved by Ivy.

Looking further, I finally found that there is a attribute in the Ivy settings file that should be set to false so that Ivy does not rely on the maven’s metadata file. This attribute is “useMavenMetadata”

e.g.,: <ibiblio name="Maven Central" m2compatible="true" useMavenMetadata="false" root="http://…" />