Versioning .NET builds

Question

Just wondering what's the best approach to versioning of .NET builds?

I use:

• TFS 2013 for version control
• TFS gated check-ins
• Wix 3.8 to package code to MSI files

I want to set version of:

• assemblies (AssemblyInfo.cs, or a shared one referenced in all projects)
• MSI packages (in Wix code)
• documentation (for example inside readme.txt file in the final output of the build)
• etc

Ideal version number would allow tracing installed software back to the exact source code.
Something like:

<Major>.<Minor>.<TFS_changeset_number>

First 2 parts of the version I want to store in some simple text \ XML file in version control near the solution, as I believe they should live together. Developers will update this file manually (for example following Semantic Versioning approach). Each build will read this version file, get 3d part of the version from the calling CI tool, and update all the necessary files with the version.

What's the best way to implement this?

I've used a few approaches in the past:

1) NAnt \ MsBuild wrapper that does this version work, then calls MsBuild for the solution. It could be called from CI tool (Jenkins \ TeamCity \ etc).

Problem - integration with TFS gated check-in is ugly as I build solution twice.

2) customize TFS build process template

Problem - it's not that simple, and causes some merge work on TFS upgrades. Also changeset number doesn't exist yet in gated check-ins, so we can only use the previous changeset id.

3) A separate MsBuild project in solution, which does only this versioning task, and is configured to run first in Project Build Order of the VS solution.

Problem - need to reference this meta-project in all other projects (including all future ones) which feel ugly

I know different MsBuild and TFS extension packs that can simplify updates. This topic is not about which one is the best. The question is more methodological than technical.

I also think that it would be ideal if Microsoft include something for versioning in their standard TFS build template. Other CI tools already have this functionality (AssemblyInfo patcher).

UPDATE 11/09/2014

I've decided to clearly express the Versioning Principles that will conform to the best practices of Agile \ Continuous Delivery:

1) Ability to reproduce any historic build

2) As a consequence of 1) and according to CD principles everything (source code, tests, app configs, env configs, build\package\deploy scripts, etc) is stored under version control and so has a version assigned to it

3) Version number is stored tightly together with the source code it applies to

4) People are able to update version according to their business\marketing logics

5) There is only 1 master copy of the version, which is used in all parts of automated build\packaging process

6) You can easily say which Version of the software is currently installed on the target system

7) Version of the installed software must unambiguously identify the source code that was used to build it

8) It's very simple to compare versions to say which is lower and which is higher - to control which upgrade\downgrade scenarios are allowed and implementation specifics of them

UPDATE 15/09/2014

See my own answer below.
I was lucky to find the solution that meets all my requirements!

Answer 1

Good grief, all those complicated answers.

In TFS 2013 this is simple. The Community TFS Build Extensions site offers a simple PowerShell to pull the build number from the build name that is assigned by TFS.

You configure your build number format to be "$(BuildDefinitionName)_6.0.0$(Rev:.r)" which will result in something like "6.0.0.1" where the "1" is incremented for each build.

You then add the PowerShell versioning script to your build and it automagically scrapes the version number above and applies it to all AssemblyInfo.* files in the build folder. You can add additional file types by updating the script.