[release/3.1] Allow Hosting Bundle to be upgraded by MU #37969
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
ghost
added
the
area-infrastructure
|
Hi @github-actions[bot]. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document. |
|
Hi @github-actions[bot]. 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. |
wtgodbe
changed the title
src/Installers/Windows/AspNetCoreModule-Setup/ANCMV2/aspnetcoremodulev2.wxs
Show resolved
Hide resolved
| <!-- Use values from the registry for switches, if the registry values are set & the user hasn't passed any switches from the command line --> | ||
|
|
||
| <util:RegistrySearch Id="opt_no_ancm_should_be_set" | ||
| Condition="NOT OPT_NO_ANCM AND NOT OPT_NO_ANCM=0 AND NOT OPT_NO_FTS AND NOT OPT_NO_FTS=0 AND NOT OPT_NO_LTS AND NOT OPT_NO_LTS=0 AND NOT OPT_NO_SHAREDFX AND NOT OPT_NO_SHAREDFX=0 AND NOT OPT_NO_RUNTIME AND NOT OPT_NO_RUNTIME=0 AND NOT OPT_NO_X86 AND NOT OPT_NO_X86=0 AND NOT OPT_NO_SHARED_CONFIG_CHECK AND NOT OPT_NO_SHARED_CONFIG_CHECK=0" |
There was a problem hiding this comment.
Find a way to put this condition in one place
| <Variable Name="OPT_NO_X86" bal:Overridable="yes"/> | ||
| <Variable Name="OPT_NO_SHARED_CONFIG_CHECK" bal:Overridable="yes" /> | ||
|
|
||
| <!-- Use values from the registry for switches, if the registry values are set & the user hasn't passed any switches from the command line --> |
There was a problem hiding this comment.
Explain how some registry values could be set while others are not. This seems significantly more complicated than it would be w/ a single check for either the registry key or one value.
There was a problem hiding this comment.
The only way that one registry value could be set and not another would be if the user manually modified the registry. But, having to create this conditional based on a registry search is sort of a WiX quirk - there isn't a direct way to assign a variable value based off of user input in a bundle. You can, however, conditionally set a variable to the value of a registry key based off of user input. We could just do this conditional check once based off of the existence of just one arbitrary registry key, but the cost of this is low and its purpose is more explicit. @joeloff do you agree?
There was a problem hiding this comment.
Yup, and for the initial deployment from MU, there would be no existing options recorded in the registry, so we want a default of 0, but if we set that initially and the user overrides it, then the registry search will win over the user's choice.
wtgodbe
added
Servicing-approved
|
Approved in tactics |
Backport of #37967 to release/3.1
/cc @wtgodbe
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:0for any switches not passed).0and write0to the registry for each switchTesting
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.