Skip to content

[release/6.0] Allow Hosting Bundle to be upgraded by MU #37967

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

Merged
merged 8 commits into from
Nov 5, 2021

Conversation

wtgodbe
Copy link
Member

@wtgodbe wtgodbe commented Nov 1, 2021

Customer Impact

Adds an .msi, dotnet-hosting-options, which writes to the registry the value of the switches used when last installing the hosting bundle for a given Major.Minor version. Subsequent installs of that band of the hosting bundle will choose what the install in the following way:

  • If the user passes any switches on the command line, use exactly those (and write them to the registry, along with 0 for any switches not passed).
  • Else use what's in the registry, if there are values in the registry.
  • Else set all switches to 0 and write 0 to the registry for each switch

Testing

Tested various scenarios with versions of the new hosting bundle across multiple Major.Minor.Patch versions, as well as how it interacts with previous Hosting Bundles without the Registry-writing behavior.

Risk

In December all customers who get this update thru MU will get a 1-time hit where, regardless of what they already had installed, the hosting bundle will install all components. We suspect most customers install everything anyways, and those who don't will be able to work around this by manually re-running the installer with whatever switches they passed the last time they installed the bundle manually. Additionally, there could be a scenario that we didn't think of (and therefore wasn't covered by our manual testing) that will break.

@wtgodbe wtgodbe requested review from joeloff, jamshedd and a team November 1, 2021 00:56
@wtgodbe wtgodbe requested a review from Pilchie as a code owner November 1, 2021 00:56
@ghost ghost added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Nov 1, 2021
@ghost ghost added this to the 6.0.x milestone Nov 1, 2021
@ghost
Copy link

ghost commented Nov 1, 2021

Hi @wtgodbe. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document.
Otherwise, please add tell-mode label.

@ghost
Copy link

ghost commented Nov 1, 2021

Hi @wtgodbe. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

@dotnet dotnet deleted a comment from github-actions bot Nov 1, 2021
@dotnet dotnet deleted a comment from github-actions bot Nov 1, 2021
Copy link
Contributor

@dougbu dougbu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All comments from #37969 apply here

@leecow leecow modified the milestones: 6.0.x, 6.0.1 Nov 2, 2021
@wtgodbe wtgodbe added the Servicing-approved Shiproom has approved the issue label Nov 2, 2021
@ghost ghost removed the Servicing-consider Shiproom approval is required for the issue label Nov 2, 2021
@wtgodbe
Copy link
Member Author

wtgodbe commented Nov 2, 2021

Approved by tactics

Key="Software\Microsoft\dotnet\host\options\$(var.MajorVersion).$(var.MinorVersion)"
Value="$(var.Option)"
Result="exists"
Variable="$(var.Option)_Should_Be_Set"/>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we rename this to '$(var.Option)_Exists' - that's the convention we typically used for existence checks. Sorry I didn't catch this earlier. It also make the second search condition a bit more readable since right now we have to similarly named variables that differ by "S" and "s"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure

@wtgodbe wtgodbe enabled auto-merge (squash) November 4, 2021 21:18
@wtgodbe wtgodbe disabled auto-merge November 4, 2021 22:00
@wtgodbe wtgodbe merged commit f8b9e54 into release/6.0 Nov 5, 2021
@wtgodbe wtgodbe deleted the wtgodbe/HostingMU6 branch November 5, 2021 00:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework Servicing-approved Shiproom has approved the issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants