Add x64 emulation support to pkg installers

[sfoslund]

No description provided.

[sfoslund]

Test run to generate assets (see Artifacts/BlobArtifacts/*.pkg): https://dev.azure.com/dnceng/internal/_build/results?buildId=1335379&view=results

Installers are being generated and installing to correct locations but when both arm64 and x64 are installed the hostFXR files only show up in the most recent installation (that is, if x64 is installed last then these files are not present in the main dotnet dir, but they are in the dotnet/x64 dir), I'm investigating if this is a result of something special in the hostfxr pkg generation or something else.

Edit: The files that are being removed are coming from packages com.microsoft.dotnet.hostfxr.6.0.0-rc.2.21451.3.component.osx.x64.pkg and com.microsoft.dotnet.sharedhost.6.0.0-rc.2.21451.3.component.osx.x64.pkg. I haven't found anything in these 2 packages' PackageInfo files or payloads that differ from the other 4 that are installing correctly.

[ericstj]

Does ARM64 and X64 use the same package identifier for host? That would cause it. My understanding of the way that MacOS identifies "upgrades" is by comparing the package identifier. If there is already a receipt on the machine for that same identifer, then it will look at the files installed by the new package to see if they are the same as the old, for any files missing from the new one it will remove them.

I can't find the docs I read about this at the moment, but sharing in case that gives a clue.

You should also be able to see this happening in the installer log. When you install the bundle, open the installer log (Windows > Installer Log) and change the view to show all logged entries.

[sfoslund]

I think you're right, it does have something to do with pkg ids. When I check what pkgs were installed, I get the following:

After installing arm64:

pkgutil --pkgs
...
com.microsoft.dotnet.sharedframework.Microsoft.NETCore.App.6.0.0-rc.2.21451.3.component.osx.x64
com.microsoft.netstandard.pack.targeting.2.1.0.component.osx.x64
com.microsoft.dotnet.pack.apphost.6.0.0-rc.2.21451.3.component.osx.x64
com.microsoft.dotnet.dev.6.0.100-rc.2.21451.26.component.osx.arm64
com.microsoft.dotnet.hostfxr.6.0.0-rc.2.21451.3.component.osx.x64
com.microsoft.dotnet.pack.targeting.6.0.0-rc.2.21451.3.component.osx.x64
com.microsoft.dotnet.sharedhost.component.osx.x64
...

After installing x64 (on the same machine):

pkgutil --pkgs
...
com.microsoft.dotnet.sharedframework.Microsoft.NETCore.App.6.0.0-rc.2.21451.3.component.osx.x64
com.microsoft.netstandard.pack.targeting.2.1.0.component.osx.x64
com.microsoft.dotnet.pack.apphost.6.0.0-rc.2.21451.3.component.osx.x64
com.microsoft.dotnet.dev.6.0.100-rc.2.21451.26.component.osx.arm64
com.microsoft.dotnet.hostfxr.6.0.0-rc.2.21451.3.component.osx.x64
com.microsoft.dotnet.pack.targeting.6.0.0-rc.2.21451.3.component.osx.x64
com.microsoft.dotnet.sharedhost.component.osx.x64
com.microsoft.dotnet.dev.6.0.100-rc.2.21451.26.component.osx.x64

Note that the pkg generated by dotnet/installer is the only one that has the correct .arm64 suffix in the first installer and as a result we see it twice (one arm64 one x64) in the second result. It appears this comes from this line in the arcade logic, which uses x64 in the pkg id regardless of the target architecture: https://github.com/dotnet/arcade/blob/fe787bd48ed72e51a98eb5e4e5e5af74edb531e5/src/Microsoft.DotNet.Build.Tasks.Installers/build/installer.singlerid.targets#L379

I've confirmed that replacing the x64 instances in the arm64 installer fixes the issue, so I'll make a PR to arcade to take architecture into account for package id.

[ericstj]

Nice find!

[ericstj]

We should file an issue to remove duplication here and leverage the arcade task

[sfoslund]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ericstj]

@sfoslund @marcpopMSFT -- what tracks getting this change into main and release/6.0.1xx? Will that be automatic? Today it's missing and it's causing those daily builds to regress this fix.

[sfoslund]

It isn't automatic, we do manual merges periodically. I was planning on merging rc2 into GA and main branches later this week once tell mode had passed, but if you need me to do it before then let me know

[ericstj]

Later this week should be fine. Right now everyone needs to be testing the RC2 builds so I think it's just about messaging to folks where to get the latest bits.