By now, we all agree that we should be versioning everything, aren’t we? For software we are delivering to production, it is the easiest way to assure that we can always determine without any doubt which source code was used to build any of the binaries being run. Fixes to production binaries should be applied over the code first used to generate them and released from there; otherwise we can be delivering not only the fix, but also half-baked features, yet-to-discover bugs and all sort of unfinished items.
The default build template in TFS 2013 has a nice new feature that allows us to run scripts (PowerShell or batch files) before or after the actual build is performed. This is useful in so many ways, and one of them is to version the assemblies being generated by preparing a script that embeds the proper version number into the AssemblyInfo.* files prior to having them built.
Fortunately, the folks maintaining the Community TFS Build Extensions have already prepared such a script for us. The script not only modifies the AssemblyInfo.* files for us, but also gets the version number to be applied from the build number. This is great because by default, each build being triggered in TFS labels the source code with the build number. And this means that we will be able to pick any assembly and trace it back to the source code that generated it by that label.
So the work of having a build definition update the version number automatically for the generated assemblies and label the code accordingly, now takes less than the time you’ll spend in reading this post:
- Download the Community TFS Build Extensions which include the ApplyVersionToAssemblies.ps1 script (after unzipping the package, look for it inside the Scripts subfolder.) Check-in the script somewhere into your source control.
- Edit or create a TFS build definition based in the 2013 default template. Inside the Build – Advanced section of the build process parameters, you’ll find that you can specify scripts to be run before or after the actual building operation takes place. For the Pre-build script path parameter, specify the path in the source control where you uploaded the ApplyVersionToAssemblies.ps1 script.
- Change the Build number format parameter so it contains a substring that can be parsed to a version number in the form Major.Minor.Build.Revision (the actual regular expression being used for parsing it is d+.d+.d+.d+) It can be anything that suits your versioning scheme; in the example below I’m just forcing everything but the revision number, which will be automatically incremented each time you trigger a build for this definition. But you can use any other scheme (for example something adhering to semantic versioning,) and take advantage of some of the provided macros.
- That’s all! The next time you trigger a build, the generated binaries should have the corresponding version number embedded in them.
Now you’ve got no excuses! Go and set up versioning for your builds before it is too late.