Deleting TFS Work Items

When setting up team projects in TFS sometimes it’s helpful to create a few test issues or bugs to make sure any customizations you have made function correctly. However, you will quickly notice there is no option to delete these work items from the UI or administrative console. It can be done though via the Command Prompt. Here’s how:

1. Open a Visual Studio Command Prompt window
   
2. Enter the following command:
   witadmin destroywi /collection:<team project collection URL> /id:<work item id>
   

For more information on using the Work Item Type Administration console utility see: http://msdn.microsoft.com/en-us/library/dd312129.aspx

Permission Work Item Types in TFS

When tracking work items for a development project you may want to capture issues reported by business users. However, giving business users access to TFS can lead to a lot of bugs getting reported that are really just issues that need to be triaged, broken down, or better categorized. One issue may be resolved by fixing 3 different bugs, 2 tasks being performed, and perhaps a test case developed. An issue can then be turned into a bug once the development team has reviewed it, or several different types of work items and related back to the original issue. But how can we ensure business users only enter issues, not bugs?

You might think work item types can be assigned permissions by user or groups. However, TFS currently doesn’t support this. There is a way though to still prevent a group of users from creating work items by type.

1. Create a global group for business users and add them as members:
   

   

2. Install the TFS Power Tools for VS if you haven’t already.
   http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f
3. The Power Tools install the Process Editor which allows you to edit work item types. Open each WIT for your project and go to the workflow tab:
   
4. Select the first transition and set Not to the business user group you just created. The prevents the first workflow step from executing if the current user is in the group.
   
5. Now users in the business group cannot save work items of type Bug:
   

Of course, this approach merely prevents users from creating work item types they don’t have access to. We still need to train business users to enter issues into TFS since the error message is not very informative. And of course security trimming would be nice but at least we have the bare minimum of access control by item type.

IIS Timeout When Debugging in VS

You can stop the Visual Studio debugger from timing out and stopping by changing a single setting in IIS. Just select the application pools you want and go to Advanced Settings in the IIS Manager.

There you can set the Ping Enabled property to False which will keep the debugger alive indefinitely.

You should also do this for the service application pool as well so things like the profile service don’t time out. Since it’s identified by a GUID you need right-click and View Applications to find the right pool.

Deployment Conflict Resolution in Visual Studio

If you are provisioning a ListInstance in Visual Studio you may see the following error message:

The URL or name of this list instance conflicts with a list instance already on the server.
The list instance on the server will be deleted before deploying the new list instance.

If you select Resolve Automatically, your list and all of its data will be removed before a new instance of the list is provisioned. To prevent this, you can set the Deployment Conflict Resolution property of the list instance in the Solution Explorer to None. Simply right-click on the list instance project item in VS and select Properties. Then select None from the dropdown list of values: