Shelveset as a Backup

Long time since I posted. Been busy (implementing TFS), long vacation and a new work place.
In the last implementation I did I have noticed that in some cases users work in a network drive that is always backed up by IT. This is a good solution for backing up your workspace without checking in your pending changes (like we used to do when we worked with SourceSafe...) or performing a shelve for backup purpose. I thought it would be nice to share the idea of automatic backup shelves with those of you that work locally without any automatic backup. When you shelve your pending changes the shelve is saved in PendingChange table. The pending changes will be removed from the table when you delete or replace the shelveset. So to perform an automatic backup of your workspace that does not overload your TFS database you can add a schedule task that will run the following command:
tf shelve {workspace name} /replace /noprompt
Remeber to set the current folder to the workspace local path before executing the command.
Enjoy.

VersionControlPath - Class to Manipulate Version Control Items Path

I was navigating through TFS assemblies and I found out a static class that I wasn't aware of: Microsoft.TeamFoundation.VersionControl.Common.VersionControlPath. This class contains functions that help manipulating version control items path. It is like the System.IO.Path class. Here are some of the methods in the class:

• GetFileName
• GetExtension
• GetFolderDepth
• Combine
• GetFolderName
• ValidatePath

Very useful.

No matching items found in {0} at the specified version

I recently got this error while trying to create a branch from that its parent was renamed.

Here's an example of what happened:

1. A branch was created at: $/Project/Folder1/Branch1.
   
2. Some work has been done on Branch1 so its history contained several change sets.
   
3. Folder1 was renamed to Folder2 ($/Project/Folder2/Branch1).
   
4. A branch operation failed while trying to create one from a change set before the rename operation with the error: "No matching items found in $/Project/Folder2/Branch1" (A branch operation on a change set created later than the rename operation will succeed).
   

I thought that the rename operation has broken the branch history. Looking at the branch dialog I saw that the source branch text box is read only and I thought to myself what would have happen if I had changed the source from $/Project/Folder2/Branch1 to $/Project/Folder1/Branch1. It was time for some coding…

private void PerformBranch(string server, string workspaceName, string userName, string changesetId, string sourceBranch, string targetBranch)

{
TeamFoundationServer tfs = new TeamFoundationServer(server);
VersionControlServer vcs = tfs.GetService(typeof(VersionControlServer)) as VersionControlServer;
Workspace workspace = vcs.GetWorkspace(server, userName);
VersionSpec versionSpec = VersionSpec.ParseSingleSpec(changesetId, userName);
workspace.PendBranch(sourceBranch, targetBranch, versionSpec);
}

This method has fixed the problem and after running it with the old branch path (source = $/Project/Folder1/Branch1), pending changes were waiting for check in.

TF20015: The field 'xxx' contains a value that is not in the list of supported values.

While trying to save a work item in TFS you might be facing a problem doing it when the error TF20015 is raised. This error is raised when you are trying to enter values that are not part of the allowed values of the field. The strange thing is that it can happen although the value was already saved before to the work item and the field is disabled. As a result you cannot change the value and therefor cannot save the work item. So why does it happen? I faced this problem in two cases:

1. The user in one of the fields (which is implementing the valid user value list as the allowed values for the field) was renamed or deleted.


2. The work item schema was changed in a way that made some of the existing work items have illegal values. For example, if you made one of the fields mandatory trough all of the work flow and you have some work items with a null value in the field.

So, how can you fix it?

There are 2 ways to do it:

1. Changing the work item schema temporarily so the field won't be disabled and then you can change the value.


2. Write some code the change the field value:

Here's a code sample on how to update work item field values:

public void UpdateWorkItem(string serverUri, int id, string fieldName, string fieldValue)
{
TeamFoundationServer tfs = new TeamFoundationServer(serverUri);
tfs.EnsureAuthenticated();
WorkItemStore wis = tfs.GetService(typeof(WorkItemStore)) as WorkItemStore;
WorkItem workItem = wis.GetWorkItem(id);
workItem.Open();
workItem.Fields[fieldName].Value = fieldValue;
workItem.Save();
}

Set Work Item Type field allowed values when another field value changes

I was asked once by a friend if there's a way to filter the allowed values of a field when another field value changes. Well, the solution is not exactly as we think about filtering but more like a switch/case mechanism.

Let's take for example 2 fields that implement OS Platform & Version selection:

Windows --> XP, 2003 Server, Vista

Linux --> Ubuntu, Red Hat, Suse

Mac --> OS X 10.0, OS X 10.5

To implement this in the work item type definition file we need to define 2 fields. The xml should look like this:

<FIELD
type="String"
name="OS Platform"
refname="MyFields.OSPlatform">

<ALLOWEDVALUES>

<LISTITEM
value="Windows" />

<LISTITEM
value="Linux" />

<LISTITEM
value="Mac" />

</ALLOWEDVALUES>

</FIELD>

<FIELD
type="String"
name="OS Version"
refname="MyFields.OSVersion">

<WHEN
field="MyFields.OSPlatform"
value="Windows">

<ALLOWEDVALUES>

<LISTITEM
value="XP" />

<LISTITEM
value="2003 Server" />

<LISTITEM
value="Vista" />

</ALLOWEDVALUES>

</WHEN>

<WHEN
field="MyFields.OSPlatform"
value="Linux">

<ALLOWEDVALUES>

<LISTITEM
value="Ubuntu" />

<LISTITEM
value="Red Hat" />

<LISTITEM
value="Suse" />

</ALLOWEDVALUES>

</WHEN>

<WHEN
field="MyFields.OSPlatform"
value="Mac">

<ALLOWEDVALUES>

<LISTITEM
value="OS X 10.0" />

<LISTITEM
value="OS X 10.5" />

</ALLOWEDVALUES>

</WHEN>

</FIELD>

The version field contains WHEN rule for each platform. The result is a field that changes in real time when the parent field value changes.

You don't have to write the xml in order to achieve this. You can use the "Process Template Editor" which is part of the Team Foundation Server power tools to easily add fields and rules to you work item.

TFSQueryExplorer

I have a new project in CodePlex named TFSQueryExplorer. It is a Visual Studio addin that looks like the Team Explorer tool window but it is dedicated to the management of queries and work items. There are a lot of cool features like manage queries in tags/folders, quick search, integration with the work item templates power tool and so on. The project is an example for using Visual Studio SDK and Team System API. I hope that you'll find it useful.

Could not load file or assembly 'Microsoft.Data.ConnectionUI' or one of its dependencies - Visual Studio 2005 SDK

I have noticed that after installing Visual Studio 2005 SDK one of my web projects has stopped running in Visual Studio raising an exception that says: "Could not load file or assembly 'Microsoft.Data.ConnectionUI' or one of its dependencies". After some investigation I have found that the file exists also under the common assemblies directory of the SDK (C:\Program Files\Visual Studio 2005 SDK\2007.02\VisualStudioIntegration\Common\Assemblies) and somehow although I do not use the assembly it is copied as a reference. The solution for that was deleting the file from the SDK common assemblies folder (since it is already contained in the framework). After the first deletion I made I had to delete another assembly from that folder and the project was running again.