Why are my files built with an extra number in the File Version?

[RichardS1]

I am building a release version of a NuGet package and the resulting File version of the assemblies is {major}.{minor}.{height}.14864, where
14864 is random. I am building with .NET build and .NET pack using the /p:PublicRelease=true.

Where is the 14864 coming from and how do I get rid of it?

Below is my version.json file:

{
   "$schema": "https://raw.githubusercontent.com/dotnet/Nerdbank.GitVersioning/master/src/NerdBank.GitVersioning/version.schema.json",
   "version": "3.2",
   "nugetPackageVersion": {
     "semVer": 2
   }, 
   "cloudBuild": {
      "buildNumber": {
        "enabled": true,
        "includeCommitId": {
          "when":  "always",
          "where": "buildMetadata"
        } 
      },
      "setVersionVariables": true,
      "setAllVariables": true
   }
}

[AArnott]

The 14864 is not random. It is the first 15 bits of the git commit hash, and can be useful when all you have is the file version to determine which commit produced the file. Specifically with the nbgv get-commits command, which will give you the exact commit. The version height is not always precise enough and get-commits will return a set of commits that might have produced it, but with the 4th integer, it's very precise.

Since the file version doesn't appear in any user-visible locations in an app or package version, I wonder if you see this value as sufficient to justify this number being present. It tends to be well-liked by others.

[RichardS1]

Thanks for the quick response.

I see where knowing the commit would be useful essential, but the AssemblyInformationalVersion contains the commit ID, which is more useful than needing to translate the 4th integer.

We do show the version on our web application so clients and QA can easily let us know exactly what version they are using if an issue arises. The 4th integer is no big deal, but we are migrating from subversion to Git and we are trying to keep the migration as transparent as possible for everyone but the developers.

I was hoping the 4th digit was optional and could be excluded.

[AArnott]

but the AssemblyInformationalVersion contains the commit ID, which is more useful than needing to translate the 4th integer.

The thing is AssemblyInformationalVersion isn't always available. Crash dumps always make file version available but AssemblyInformationalVersion may not even be represented in them.

There is no option to suppress the 4th integer from File Version. But ultimately everything is customizable via msbuild. One target generates all the msbuild properties and another target uses them to generate the assembly atttributes. If you define your own target that runs in between these two (use MSBuild's BeforeTargets attribute) then you can change the AssemblyFileVersion property to be whatever you like.
In particular you may find the BuildVersionSimple property (set here) to be useful as it is set to the 3-integer version.