Using SourceVersion and rev:r in TFS2015 build names - tfs

Question

We have a process we worked out with our XAML builds that used the TFS change set number in the name of the individual builds. We are trying to convert some of these builds to the new build system on TFS 2015 and running into issues getting change set into the build name.
If we use $(Build.SourceVersion)$(Rev:.r) in the Build Number Format field of the build definition, we get an output of C12345.1 on a triggered build, but then .1 on a manually queued build. We would expect to see C12345.2. Lots of research boils down to, $(Build.SourceVersion) has to be manually entered when the build is queued in order for it to be populated when the Build Number is calculated.
Ok, so we dropped into PowerShell to try to manipulate the build numbers. Once in the PowerShell task, Build.SourceVersion is populated with the correct value. We tried having the Build Number Format of the definition just be $(rev:r), which allowed us to get it in PowerShell, combined it with the Source Version value, and using the result to update the build number via the logging command Write-Host "##vso[build.updatebuildnumber]"$buildVersion. This gives us an output of 12345.1 on both the triggered and manual builds, but rev:r never increments, since there are no builds matching the pattern found in the Build Number Format at the time it is calculated. So manually queuing the builds ends up with any number of them that have the exact same name.
Does anyone have a recipe for getting a build name that reliably contains the Source Version and Revision values where everything increments correctly for both triggered and manual builds?

Answer 1

No, It's not able to do this. You need to understand the token $(Rev:.r) first:
What is $(Rev:.rr)?
To ensure that every completed build has a unique name. When a build
is completed, if nothing else in the build number has changed, the Rev
integer value is incremented by one.
Source:MSDN
In your scenario you set the build number format as $(Build.SourceVersion)$(Rev:.r), if the value of $(Build.SourceVersion)changed, then the value of $(Rev:.r) will not be incremented, it will always keep "1". Only the value of $(Build.SourceVersion) keep the same, then $(Rev:.r) will be incremented.
Besides, based on my test, the variable $(Build.SourceVersion) in build number format is only available when builds were triggered automatically on commit/checkin (on Continuous integration). It can not be resolved when you queue build manually and keep the Source Version field as empty (by default it will get the latest version). So, if you queue build manually, then you need to specify the specific Source Version (e.g C458) in the queue build dialog.
However if you want to set the builds name as incremental ones, you can update the build number manually with the REST API:
PATCH http://server:8080/tfs/Collection/Project/_apis/build/builds/{buildId}?api-version=2.0
Content-Type: application/json
{
"buildNumber": "TEST.20170123.1"
}

Answer 2

So after much research and trial & error this is the closest we managed to come to our desired output...
The Build number format is set to $(Build.SourceVersion).$(Build.BuildId) in the configuration.
We use a powershell script to parse the Assembly File, Source Version, and Build Id to come up with a full 4 part version number in the form of Major.Minor.ChangeSet.BuildId.
We push this new version number back to our build number using Write-Host "##vso[build.updatebuildnumber]"$buildNumber
We also used the Assembly Info step to push this calculated version number back to the actual build process, so that the DLLs come out with the same version number as the build.
This gets us a version number that is unique for each build, and points back to specific a particular state of the source, which was the priority. What we lose is the nicely incrementing build numbers that reset with each change. Instead we have a number that increments for every build that occurs anywhere in the system, and never resets.