When errors occur in applications developers use stack traces to to help them figure out where in the code something went wrong. The stack trace reports the the class and method from which an error originated, and depending on availability of debug symbols which line in the source file each of those class and methods up the call stack are associated.
Sometimes however it can be challenging to find the correct set of source files that were used to compile up the application.
Team Build helps by generating a unique build number whenever it produces a build, and placing all the build outputs into a specific drop folder, but it can be hard to trace back from a single DLL in production to the build number that it came from.
This is where build stamping comes in. Build stamping (not sure if this is what everyone calls it) is a technique where you embed some kind of identifier into the assembly metadata. A lot of people use a standard .NET version string (w.x.y.z) but I prefer to use the build number from Team Build (e.g. TrunkHelloWorld_20070830.5) and put it in something like the assembly description.
First, download and install the latest build of the MSBuild Community Tasks mentioned above. This set of libraries and custom build targets. Next you need to add the following code (Import element, and Target element) to the TFSBuild.proj file under the Team Build Type definition.
This will, then, during a build update all the AssemblyInfo.vb (or AssemblyInfo.cs if you change it accordingly) files under the solution root and replace the text “DeveloperUseOnly” in those files with the build number. All you need to do is put that text inside the metadata element where you want the information to appear and bingo – you are now stamping the builds with the Team Build build number.
I’d recommend putting it in the description because it shows up in the list of properties when you right mouse click the file in Windows Explorer.