Version not extracted from BuildNumber with regex

[DavidDeSloovere]

Just installed this promissing extension and I like how it works. I was already moving into an advanced scenario with build numbers.
I have a build number format $(Build.DefinitionName)_2.1$(rev:.r).0 that results in a build number like this: NatchSandbox-Deploy-Linux_2.1.2.0
According to the WIKI, I was expecting the extension to extract 2.1.2.0 from that, but it took the whole build number instead. Did I misread or am I doing something wrong?
I checked the regex in the source and I don't really see an issue. I also tried without the trailing .0.

[tomaustin700]

This is still an issue.

[tomaustin700]

Looking at this further I believe the issue is due to line 128 in index.ts. informationalVersion should be set using the regex matched version like how it is done with version and fileVersion i.e.

const informationalVersion = model.informationalVersion.match(regex.version);
const informationalVersionValue = informationalVersion && informationalVersion [0] || '';`

model.informationalVersion = utils.setWildcardVersionNumber(informationalVersionValue, model.verBuild, model.verRelease);

Would you like a PR raising with this fix?

[BMuuN]

The version number will be extracted from the build number format however this is only true for the fileVersion and version fields. Both fields only allow numeric values in the format major.minor.build.revision (in you example above, 2.1.2.0).

The packageVersion and informationalVersion can by any string that represents additional version information and is included for informational purposes only. For this reason the build number is not extracted and the entire build number is used NatchSandbox-Deploy-Linux_2.1.2.0.

Additional information surrounding this functionality can be found on the following issues: #49, #24, #68

You can read more about the fields here:

• https://docs.microsoft.com/en-us/dotnet/framework/app-domains/assembly-versioning
• https://docs.microsoft.com/en-us/dotnet/standard/assembly/set-attributes

I can see how the Wiki is misleading around this functionality and I will aim to get this updated a.s.a.p. Apologies for any confusion this has caused.

[BMuuN]

Off the top of my head the only way to overcome the issue you're both facing would be changing your build number format, for example:

1. On your build definition create a build variable "AppVersion" and set its value to 2.1.$(Build.BuildId).0
   (unfortunately $(rev:.r) will only work from the Build Number Format filed).
2. On the Build Number Format filed set it to $(Build.DefinitionName)_$(AppVersion)
3. On the Assembly Info task set the "Informational Version" field to: $(AppVersion)

This approach will ensure your build name includes the version number that's set in your assemblies and your Informational Version will contain the version number only.

[tomaustin700]

@BMuuN If you set informational version to something that contains text the following error is thrown when running dotnet restore

 C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : 'Release_8.22.19333.5' is not a valid version string. (Parameter 'value') [C:\Build Agent\_work\179\s\Identity\Identity\src\Identity.sln]

I managed to get around it by writing a powershell script to strip the build name, assign this to a pipeline variable and then use that in the task to set the informational version.

[BMuuN]

That error is thrown when Release_8.22.19333.5 is set as the "Package Version".
The build completes successfully when Release_8.22.19333.5 is set as the "Informational Version".

Can you double check the task output to ensure the Assembly Info task version is v2.0.73

[BMuuN]

Closing as this is a non-issue as mentioned above.