Grant Holliday

This console application lists the last modified date of each file from the TFS changeset history. It was created to mimic the last modified information provided by Visual SourceSafe Explorer. You may find it useful when creating release notes for your applications, although it would be better to rely on TFS labels and changeset IDs.

Usage: TfsLastModified <server url> <path> [/vssdates]

The /vssdates parameter will retrieve the comment for each item and parse the imported VSS date of the format “{date} comment”.

Example: TfsLastModified http://tfsserver:8080/ $/TeamProject/Folder/Folder

Download

You can download the source and binaries from the TFS LastModified project page on ProjectDistributor.net

I had hoped to make this available as a Visual Studio addin as well, but I’ve struggled to find the time – so I’m releasing this instead of nothing at all. If you do find it useful, leave a comment or send an email to the OzTFS mailing list. Enjoy!

Eric Lee has updated his Work Item Moving Tool. You can read more about it on his blog.

Without something like this, you have two options for moving work items between Team Projects.

The first option is to right click on each invididual work item and move them that way. The second option is to use Microsoft Excel to copy and paste the contents across projects. This is the quickest (until now), but you lose valuable links and attachments.

Another question came up in the course today relating to the TFS Team Build server. “Can I configure a build server to use the TFS proxy as well?”

Once again, I found the answer in the MSDN forums.

Yes you can. You have to edit the registry on the build server and add the following key. I assume that you could also do this using Team Explorer if you had it installed on your build server. You would go to Tools | Options | Source Control | Visual Studio Team Foundation Server

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl\Proxy]
“Enabled”=”True”
“Url”=”http://TeamServer1:8080″

A question came up in the course today about TFS Proxy Server. For those who don’t know, this proxy server is used when you have a remote site and want to speed up version control operations back to the main server.

For example, you might have your main TFS installation in a data-centre and then run a local TFS Proxy server on-site. Or you might have your main installation in Canberra with a proxy server in Sydney, Brisbane and Melbourne.

The question came up “Do I need to run two proxy servers if I want to talk to two TFS servers?”. I didn’t know the answer myself, so I went looking.

In the MSDN article How to: Enable Source Control Caching for Team Foundation Server Proxy it talks about the Proxy.config XML configuration file. This file has a <Servers> element that accepts multiple <Server> definitions. So the short answer is “Yes, it does!”.

So your Proxy.config would look like this:

<Servers>
 <Server>
  <Uri>http://TeamServer1AT:8080/VersionControl</Uri>
 </Server>
 <Server>
  <Uri>http://TeamServer2AT:8080/VersionControl</Uri>
 </Server>
</Servers>

Looking at Microsoft’s own TFS deployment topology, they have all their main TFS servers in Redmond with a proxy server in India, North Carolina, etc. Also, remember that the proxy server only caches version control “gets”, all your work item operations and commits have to go back to the main server.