Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[release/7.0] wasm-tools: Fix workload manifest MSI ProductVersion generation #91015

Merged
merged 1 commit into from
Aug 24, 2023

Conversation

joeloff
Copy link
Member

@joeloff joeloff commented Aug 23, 2023

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. 7.0.11.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 7.0.10, the ProductVersion generated using the old method was 56.3.64668 and for 7.0.11 it generated 56.0.812.

Impact

  • Visual Studio PR checks fail package validation because the new MSI's version is lower than the baseline copy from the previous insertion.
  • The CLI will block installing the newer manifest when trying to update workloads because it will detect a possible downgrade.

Testing

No unit tests for this. Need to manually verify the manifest MSI's ProductVersion matches the version we generate for other runtime MSIs as well as the workload component version.

@joeloff joeloff added Servicing-consider Issue for next servicing release review area-Workloads Workloads like wasm-tools labels Aug 23, 2023
@ghost ghost assigned joeloff Aug 23, 2023
@joeloff
Copy link
Member Author

joeloff commented Aug 23, 2023

/backport to release/8.0

@github-actions
Copy link
Contributor

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/5956389034

@teo-tsirpanis
Copy link
Contributor

The PR should target the release/7.0-staging branch.

@mmitche mmitche merged commit 6c6a10c into dotnet:release/7.0 Aug 24, 2023
172 of 175 checks passed
@carlossanlop
Copy link
Member

The PR should target the release/7.0-staging branch.

No, this was done on purpose so it flows to internal quickly. The bot flowed this to staging automatically: #91071

@carlossanlop carlossanlop added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Aug 24, 2023
@leecow leecow added this to the 7.0.11 milestone Aug 24, 2023
@ghost ghost locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Workloads Workloads like wasm-tools Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants