TFS Work Item Manager Breaks when changing Iteration Dates when storing in settings in TFS

We recently ran into an issue when we were trying to add iterations, or change existing dates for an iteration,  to a project in TFS Dashboard.  The TFS Dashboard, made by Telerik, uses dates provided in the file created by Work Item Manager (WIM) and stored in TFS (if selected.)  This will break when using TFS 2010 Check-in policies.  The purpose of this posts is to help you understand how to get around this.

Background:  Where Work Item Manager stores Project Metadata

While configuring each project to display as part of your TFS Dashboard, you will often get prompted if you’d like to store information for this project in TFS.  For many of you, you may not be aware of where “TFS” means and if you take time to check source control you might find some oddities.

The above dialogue, when you answer Yes, will create a folder named settings in project’s source control which is very handy if you are like us and have multiple displays throughout our offices of projects.  This ensures that each instance of the dashboard.exe are loaded with the same settings, images, and sounds.  The alternative, if you choose No, is that each copy of the dashboard is loaded with settings stored in DashboardConfig.xml & ProjectMetadata.xml locally rather than on the TFS server.

If you’ve already setup your projects in TFS Dashboard and you’d like to start using source control, you can easily do so after the fact by opening up the dashboard settings from Work Item Manager.

To change your project to utlize source control, do the following:

1. Open TFS Work Item Manager
2. Click View from the “ribbon”
3. Select Dashboard Settings
4. Under Dashboard Configuration Settings, click Projects
5. For each project, check to “Store and use settings on your TFS Server”
6. Click Save

After selecting to store, you can open  source control via Team Explorer and you should see for each project the following-

Source Control Check-in Policies & TFS Dashboard

As I mentioned, this system of storing settings on your TFS server works great unless your team is using check-in policies for TFS.  Check-in policies ensure that your development team is following engineering practices set out by your team for each check-in.  For example, you might have check-in policies like-

• TFS Work Item is associated with check-in
• TFS Work item is associated & resolved with check-in
• Code analysis is executed

These are all exposed for each project by doing the following -

1. In Team Explorer, right-click on the project, select Team Project Settings, and click Source Control…
2. Click Check-in Policy tab

If you have anything listed in the Check-in policy, TFS Dashboard settings updates will fail when you are updating iteration dates via the iteration schedule.

Changing Iteration Dates & Error w/ Check-In Policies Enabled

Let’s assume for the purposes of this example that you are an agile team that has releases often, therefore, you are often adding iteration dates to your release.  This requires that you change the iteration dates via TFS Work Item Manager to ensure that when TFS Dashboard is ran it is appropriately looking at the right iterations.  Otherwise, TFS Dashboard always shows the status for backlog which isn’t helpful since items in the backlog aren’t worked on.

To add or modify iteration scheduling in TFS Work Item Manager, do the following:

1. Open TFS Work Item Manager
2. If not already connected to the project, click Connect on the Home tab and connect to the project
3. Click the View tab
4. Click Iteration Schedule
5. Click “Sync from TFS” to ensure that all iterations are pulled from TFS
6. For each iteration, enter a start and end date
7. Click Save

At the top of TFS Work Item Manager, you have a save button that will commit the changes.  If you do not have check-in policies, then all should work fine and your updates will start on the next refresh.  How to workaround the issue – A Case Study from the Weeds

Workaround:  Two ways to get by Check-In policies when using TFS Dashboard

The more obvious fix to this problem is to not have check-in policies.  In our case, we believe this to be unacceptable so we had to determine other ways to fix this.  This should help those of you just like our development team.

The first method to fix this is to disable, albeit temporarily, check-in’s for the project.  This is a rather trivial exercise by doing the following-

1. Open Team Explorer
2. Right-click project, select Team Project Settings, Source Control…
3. Under check-in policies, highlight the policy and click disable
4. 
5. Open TFS Work Item Manager, click View, Iteration Schedule, and modify the settings you desire
6. Click Save
7. In Team Explorer, highlight the policies and re-enable

The second option isn’t so clean and can occur when the TFS Work Item Manager returns you an error for the project when attempting to save.  When this problem occurs the result is TFS Work Item Manager is allowed to open the file, ProjectMetadata.xml, and it is saved locally (via mapped folder) but not allowed to check-in.

When you open source control, look at the file, it will have pending changes that haven’t been checked-in and you can check them in using normal procedures. 

Summary

In today’s post, I outlined how you could continue your gated check-in’s in TFS and ensure that you can utilize TFS Work Item Manager Dashboard “Shared” settings.  The dashboard offers you the opportunity to store your files in source control under a folder named ‘settings’ for each project.  It will store information such as pictures and any custom sounds you might utilize so that if you use the dashboard in multiple locations then they are look the same.  If you don’t choose this option, then each instance of the dashboard is stored locally on the system.  Happy reporting with the dashboard…

Enjoy!

Thanks,

-Chris