- GetFileName
- GetExtension
- GetFolderDepth
- Combine
- GetFolderName
- ValidatePath
Very useful.
toolsmith is the software equivalent of a tool-and-die specialist; one who specialises in making the tools with which other programmers create applications. [Jargon File]
Very useful.
I recently got this error while trying to create a branch from that its parent was renamed.
Here's an example of what happened:
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.
So, how can you fix it?
There are 2 ways to do it:
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();
}
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.