tfs - Versioning .NET builds -

just wondering what's best approach versioning of .net builds?

i use:

• tfs 2013 version control
• tfs gated check-ins
• wix 3.8 package code msi files

i want set version of:

• assemblies (assemblyinfo.cs, or shared 1 referenced in projects)
• msi packages (in wix code)
• documentation (for example inside readme.txt file in final output of build)
• etc

ideal version number allow tracing installed software exact source code.
like:

<major>.<minor>.<tfs_changeset_number> 

first 2 parts of version want store in simple text \ xml file in version control near solution, believe should live together. developers update file manually (for example following semantic versioning approach). each build read version file, 3d part of version calling ci tool, , update necessary files version.

what's best way implement this?

i've used few approaches in past:

1) nant \ msbuild wrapper version work, calls msbuild solution. called ci tool (jenkins \ teamcity \ etc).

problem - integration tfs gated check-in ugly build solution twice.

2) customize tfs build process template

problem - it's not simple, , causes merge work on tfs upgrades. changeset number doesn't exist yet in gated check-ins, can use previous changeset id.

3) separate msbuild project in solution, versioning task, , configured run first in project build order of vs solution.

problem - need reference meta-project in other projects (including future ones) feel ugly

i know different msbuild , tfs extension packs can simplify updates. topic not 1 best. question more methodological technical.

i think ideal if microsoft include versioning in standard tfs build template. other ci tools have functionality (assemblyinfo patcher).

update 11/09/2014

i've decided express versioning principles conform best practices of agile \ continuous delivery:

1) ability reproduce historic build

2) consequence of 1) , according cd principles (source code, tests, app configs, env configs, build\package\deploy scripts, etc) stored under version control , has version assigned it

3) version number stored tightly source code applies to

4) people able update version according business\marketing logics

5) there 1 master copy of version, used in parts of automated build\packaging process

6) can version of software installed on target system

7) version of installed software must unambiguously identify source code used build it

8) it's simple compare versions lower , higher - control upgrade\downgrade scenarios allowed , implementation specifics of them

update 15/09/2014

see own answer below.
lucky find solution meets requirements!

good grief, complicated answers.

in tfs 2013 simple. community tfs build extensions site offers simple powershell pull build number build name assigned tfs.

you configure build number format "$(builddefinitionname)_6.0.0$(rev:.r)" result in "6.0.0.1" "1" incremented each build.

you add powershell versioning script build , automagically scrapes version number above , applies assemblyinfo.* files in build folder. can add additional file types updating script.