[release/6.0] wasm-tools: Fix workload manifest MSI ProductVersion generation #90994
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Manifest installers for .NET optional workloads rely on performing major upgrades in .NET 6 and 7. This requires that the MSI version increments for new builds. The MSI version was generated using the assembly version. MSI versions should be generated using the major/minor/patch/buildnumber, e.g. 6.0.20.12345. Because the assembly version was being used, the patch value was always set to 0. Due to the bit masking and shift operations used to construct the MSI version, the 3rd part of the version number wrapped around, generating a smaller version for a newer release. MSI ProductVersion is only 32-bits in size (8-bit major, 8-bit minor and 16-bit build number).
For 6.0.21, the ProductVersion generated using the old method was 48.3.64667 and for 6.0.22 it generated 48.0.763.
Impact
Testing
No unit tests for this. Validated using Orca to ensure the manifest MSI's ProductVersion matches the version we generate for other runtime MSIs.
The generated component manifest for the wasm-tools workload in Visual Studio using an internal build was also validated. The component uses the runtime's AssemblyFileVersion as it can rely on a standard 4-part version number.