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/6.0] x64 on arm64 fixes #7906

Merged
merged 6 commits into from
Sep 18, 2021

Conversation

ericstj
Copy link
Member

@ericstj ericstj commented Sep 17, 2021

Installer work to support x64 on arm64. This is a cherry-pick of all relevant arcade changes.

This work will require additional changes in Runtime, ASPNETCore, and Installer to achieve the desired side-by-side characteristics of x64 installed on ARM64.

Customer Impact

Customers want to install our x64 product on arm64 machines in order to run x64 targeted applications.

Testing

We have tested the Windows - runtime consumption of these in main and confirmed it produces installers which behave as we expect. We have tested the changes in isolation as well. It is difficult to test the full end-to-end due to 7.0 not having coherent builds and these changes spanning many repos to realize full end-to-end.

Risk

Low - as designed these changes should not impact existing working scenarios. The risk here is that we have a bug that accidentally impacts those scenarios. We've tried to mitigate that through testing consumption in main. We'll also mitigate by testing bits out of RC2 branches as soon as these changes flow.

sfoslund and others added 5 commits September 16, 2021 22:54
* Adding detection and retargeting of DOTNETHOME

When x64 is installed on non-x64 machine, place in an x64 subdirectory.

* Remove test value of dotnet folder

* Fix ProgramFilesFolder preprocessor variable usage

* Refactor Set_DOTNETHOME_x64 into a single shared source file

* Add CA ID for INSTALLING_IN_EMULATION.

* Define Platform consistently

* Move workload registration to platform specific

* Refactor INSTALLING_IN_EMULATION property

Don't need to use a registry search since environment of the MSIServer
process can be read (TBD pending reccomendation from MSI team).

Also make property work for any architecture, in case we wish to use
it more generically (EG: to condition PATH entry in host installer).

* Make platform comparison case insensitive

* Respond to feedback
The bundle was passing in a hardcoded DOTNETHOME value unconditionally
to MSIs in the chain.  This value doesn't have the redirection we're
adding to the MSI.  We can't add that redirection in the bundle, since
Burn doesn't have conditional variables.  It can only set variables as a
result of a search to either the value of the search (if successful) or
1/0.
* Adding x64 emulation support for pkg installers

* PR feedback

* PR feedback
@ericstj
Copy link
Member Author

ericstj commented Sep 17, 2021

Waiting to add #7913 to this PR.

* Update mac x64 installer script arch detection

* Add comments to x64 machine detection script
@ericstj ericstj added servicing-approved Approved for servicing and removed * NO MERGE * servicing-consider Servicing ask-mode labels Sep 17, 2021
@ericstj
Copy link
Member Author

ericstj commented Sep 18, 2021

(approved over email) Looks like I can't merge arcade release changes. @mmitche @markwilkie?

@ericstj
Copy link
Member Author

ericstj commented Sep 18, 2021

(please merge commit, no squash)

@markwilkie
Copy link
Member

The repo is setup to not accept merge commits (only squash). Want me to do that?

@markwilkie markwilkie merged commit dd9dbfe into dotnet:release/6.0 Sep 18, 2021
@markwilkie
Copy link
Member

nm - I just temporarily turned on merge commits and did it. (they're back off now)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
servicing-approved Approved for servicing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants