How do we specify a 3 segment Assembly Version (i.e. 0.4.1)?

I am attempting to migrate an existing project to Nerdbank.GitVersioning. The thought put into how this works in CI environments is great, which is why we would like to use it on this project.

However, we are running into trouble because there doesn’t appear to be a way to specify a 3-segment AssemblyVersion number, which is what the existing version specifies.

Existing Version from NuGet

PackageVersion: 0.4.1

[assembly: AssemblyVersion("0.4.1.0")]
[assembly: AssemblyInformationalVersion("0.4.1.0 commit:[15dc7a18b9]")]

Patch Version

Since this is a port of 0.4.1, we cannot change that part of the version number without causing user confusion (unless of course we also port over the changes from 0.4.2 or next higher version that exists). So, the patch should be versioned as follows.

PackageVersion: 0.4.1.1

[assembly: AssemblyVersion("0.4.1.0")] // Must remain the same for binary compatibility on .NET Framework
[assembly: AssemblyInformationalVersion("0.4.1.1 commit:[xxxxxxxxxx]")]
[assembly: AssemblyFileVersion("0.4.1.1")]

What we tried

First I tried setting the <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>, but that doesn’t have any effect on the output of Nerdbank.GitVersioning.

I looked at the schema of version.json to see if there was an option to specify it explicitly and found "assemblyVersion" can be. But there is a problem: It defines the version as major.minor, so when I specify "0.4.1" it shows a warning and the AssemblyVersion is generated as 0.4.0.0 rather than the expected 0.4.1.0.

Short of completely disabling Nerdbank.GitVersioning for our release build and using a custom script, is there any option to specify 0.4.1 as the AssemblyVersion?

[AArnott]

These properties feed into the versioning that is stamped into your .NET assembly. Nerdbank.GitVersioning writes to these properties as part of the version calculation. If you want to override them, it can only be done as I specified, as global properties set with the /p: switch. Global properties cannot be overwritten in msbuild execution so although nb.gv will try to write to them, the new values will be discarded and your global properties will win.

But again, I hope to have a much better answer for you soon.

[AArnott]

Makes sense. I’ll look into this later today.

Regarding your precision: major policy in general, that makes sense. I personally use minor as a default because adding new APIs is a forward-breaking change. That is, if someone compiles against 1.3.0.0 and then runs against 1.2.0.0, it’ll fail if they use any of the new APIs added in 1.3.0.0. Investigating and fixing the bug is much faster with an exception about v1.3.0.0 not being found instead of a particular method not being found. So my own policy is all new APIs require a minor version bump, and that shows up in the assembly version. Yes, that means apps that use my libraries often need binding redirects, but those are usually auto-generated by msbuild nowadays anyway so it’s rarely a problem.