Account for target installer arch in mac pkg id generation

[sfoslund]

Fixes dotnet/installer#11813 (comment)

[sfoslund]

I'm not sure how to validate this change, so please point me in the right direction for unit tests/ manual validation.

[ericstj]

@dagood, @agocke, or @jkoritzinsky might have an idea for how to test. My guess is the best bet is to just apply the patch and build locally and test the installers.

For my MSI changes I built private copies of the SDKs then ingested those into a full runtime build in PR. I'm not sure you need to do that for such a small change as this.

[ericstj]

This is the right change to make, but it means that ARM64 installations are not going to upgrade well WRT removing the old files. We might need to document that those should be manually cleaned up if folks wish to do so.

[dagood]

Maybe also consider/test what'll happen if someone installs x64, then installs arm64, then upgrades x64 to the next release.

And perhaps a more interesting subscenario in the future: what if the first x64 installer installs to /usr/local/share/dotnet, the arm64 installer replaces some files, and then the second x64 installer has the logic to install to /usr/local/share/dotnet/x64? (Would the x64 upgrade delete files from the arm64 install because it thinks the old x64 installer was the one to place them down? I'm not familiar with how these files are tracked.)

[ericstj]

what if the first x64 installer installs to /usr/local/share/dotnet, the arm64 installer replaces some files, and then the second x64 installer has the logic to install to /usr/local/share/dotnet/x64

I believe we scoped out upgrade from pre x64-on-ARM64 installers, since the assumption is most of the ARM64 machines will be new installs. @richlander is that correct? It still may be interesting to understand what happens since that could be a state folks get into.

[ericstj]

We'll need more changes eventually, not sure if it's this PR or a follow up.

The bundles produced from this use a template: https://github.com/dotnet/runtime/blob/c2bd3ca1c2815a6550996bbc62719421aaaaccca/src/installer/pkg/sfx/bundle/shared-framework-distribution-template-x64.xml#L2

And task:

arcade/src/Microsoft.DotNet.Build.Tasks.Installers/src/GenerateMacOSDistributionFile.cs

Line 33 in 0ec8dba

public override bool Execute()

[sfoslund]

@mmitche who from the arcade side would be best to review this?

[dagood]

idea for how to test. My guess is the best bet is to just apply the patch and build locally and test the installers.

Yeah, AFAIK nobody got to automated testing. I'm not even sure if we have access to "blank slate" VMs/images to run things on. At least, the hosted macOS agents say they have a ton of .NETs installed.

IIRC I had to use pkgutil --forget and manually delete files between attempts, since macOS in general doesn't support uninstalls.

[dagood]

Maybe also consider/test what'll happen if someone installs x64, then installs arm64, then upgrades x64 to the next release.

And perhaps a more interesting subscenario in the future: what if the first x64 installer installs to /usr/local/share/dotnet, the arm64 installer replaces some files, and then the second x64 installer has the logic to install to /usr/local/share/dotnet/x64? (Would the x64 upgrade delete files from the arm64 install because it thinks the old x64 installer was the one to place them down? I'm not familiar with how these files are tracked.)

[sfoslund]

We'll need more changes eventually, not sure if it's this PR or a follow up.

I plan on making these changes in a follow up PR, likely next week. In the meantime, is this good to merge?

[ericstj]

Yep, let's do it. We can validate this work in 7.0.