Take the 2-minute tour ×

I'm looking for a way to extract changeset number or revision number information from a TFS workspace at build time, while potentially offline from the TFS server.

The specific problem is as follows. I am attempting to port a cross-platform (Linux/g++/make and Windows/VS2010) C++ codebase from SVN to TFS. As part of the build process, the Makefile (on the Linux side) or VS build properties are set up to automatically create a 'version' file, that contains the filtered output of the svnversion or SubWCRev command. This information is used to report not only the revision number and modification state of the main executable, but also of the component static libraries that are built and are used to link against.

A complicating issue is that our TFS server is on the end of a VPN in another state, and is not reliably available. It is important to be able to build the code locally while not connected to the TFS server. The TF command-line tool, as far as I can tell, insists on attempting to establish a connection, or reports that I do not have permission to access the remote resource.

The current VS/TortoiseSVN approach just has a custom build step (executes after "PreBuildEvent"), which calls SubWCRev and then filters the output to make it compatible with the output from svnversion, finally writing it to a header file:

set bv=$(IntDir)\$(ProjectName)_bv.h
SubWCRev "$(SolutionDir)\..\$(ProjectName)" | sed "s/:/ /g" | gawk "/revision/ {r=%24(NF)} /modifications/ {m=\"M\"} END {print \"#define $(ProjectName)_bv \\\"\" r m \"\\\"\"}" > "%bv%.tmp"
fc "%bv%" "%bv%.tmp" 2>nul >nul || copy "%bv%.tmp" "%bv%"

Can anyone offer a similarly straightforward solution for use with intermittently-connected TFS?

Any help is much appreciated!

share|improve this question
TFS and SVN are very different.. there's a lot less information carried into the TFS workspace for one. I would suggest 1. having a manual build step for creating the version file (how often do you need this updated?); 2. setting up a TFS proxy (you'll be surprised how easy and efficient this is, all you need is a spare machine); or 3. just let the TF command line do what it wants and provide a really big timeout (or allow 10's of retries). –  Jonno Sep 23 '12 at 14:11
I'm really hoping to keep this as automated as possible — it's all too easy for a manual step to be skipped! But perhaps these version files can be created at check-in or check-out time? Is TFS scriptable in this manner? The proxy option, unfortunately, is unavailable to us. Further, even when connected, having the TF client prompt for login information every invocation would make building the project super-tedious, and the other developers would very quickly come to have no truck with it. –  Sam Yates Sep 23 '12 at 23:49
I agree - manual steps can be easily forgotten, however you may find that the cost of trying to automate this often means you're better off just having the build report what version it has just created rather than getting it to put the right number in. TFS has event hooks.. it is scriptable but perhaps try to explain why you need the version file changed so often? And why is it TFS-dependant? I can agree with a production or QA build (automated build) having a version in some way calculated by TFS, but why is that necessary in your developer environment, and so often? –  Jonno Sep 24 '12 at 1:38
The code is essentially a simulator; before deployment, we run the simulator over various datasets to ensure the behaviour is sane, appropriate, timely, etc. By storing the revision number in the simulator output, not only can we ensure that bugs in production can be attributed to a particular build, but more crucially, we have a history of a certain exhibited behaviour being tied to a certain state of the code base in our pre-deployment testing. In practice, it has been very easy for people to attribute incorrect or bug-fixed behaviour to the wrong version of the code. –  Sam Yates Sep 24 '12 at 3:43
OK. Do you have an automated build process? I think (?) you'd agree it makes the most sense to put a version against a deployed build. However in the development environment it is probably not necessary. If that's the case you can narrow down the use case for the "revision updater" (doesn't have to run on every developer's machine every time they compile). The TFS API (regardless of whether you're using TFS Build or not) allows to programmatically check out, change (version file) then commit. Alternatively you could use a flag or environment variable so that no check in is required. –  Jonno Sep 24 '12 at 4:42
show 3 more comments


Your Answer



Browse other questions tagged or ask your own question.