Runtime support for multi-architecture installations

[agocke]

The fundamental architectural difference here is that some platforms provide support for multiple architectures, e.g. they run ARM natively, but provide an emulator for amd64.

There are a couple areas we need provide support for:

1. Installations of shared frameworks with multiple architectures
2. Deployment of standalone apps with multiple architectures

There are two OSes we want to focus on: Windows and Mac OS.

We now have proposed designs for the shared framework/global install of .NET:

• Add plan for x64 emulation designs#217
• https://github.com/dotnet/designs/blob/main/accepted/2021/install-location-per-architecture.md

Work items:

• Agree on the path format for the architecture-specific default install locations.
• Embed the default install location for each different architecture into the apphost.
• Add a mechanism into the apphost to retrieve the OS architecture in which the process is running.
• Extend the global install location config file (macOS and Linux)
  • Add support for downlevel apphost compat: installers should keep the first line of the config file as is, while adding architecture-specific lines.
  • Add logic for picking up the correct installation (search for the arch-prefixed line matching the current architecture and fallback to the non-prefixed line if none was found).
• Modify apphost to pick the correct arch-specific DOTNET_ROOT_ARCH env variable first and fallback to the default DOTNET_ROOT if it wasn't found.
• Add multi-arch support for self-registered installations using Windows Registry.
• Include all architectures in commands line dotnet --info - Host should inform user about other installed archs on the system #51101
• Include all architectures in errors about missing runtime/framework - Host should inform user about different archs when failing to find framework #51102
• Extend test infra to easily mock the OS and architecture so that testing can be done anywhere.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The fundamental architectural difference here is that some platforms provide support for multiple architectures, e.g. they run ARM natively, but provide an emulator for amd64.

There are a couple areas we need provide support for:

1. Installations of shared frameworks with multiple architectures
2. Deployment of standalone apps with multiple architectures

There are two OSes we want to focus on: Windows and Mac OS.

The questions are:

• Some OSes (Mac OS) provide support for building universal binaries. Do we want to use that?
  • Which files do we want to use universal binaries? Single-file support?
• How to install multiple frameworks side-by-size in a shared install directory such that the muxer can find the appropriate arch?

Author:	agocke
Assignees:	-
Labels:	area-Host
Milestone:	-

[vitek-karas]

dotnet --info behavior improvement: #51101
Note that this is an existing problem for Windows x86/x64, Apple M1 and future Windows arm64 are just more examples of the same.

[vitek-karas]

dotnet app.dll behavior improvement: #51102
Just like above, this is an existing problem on Windows x86/x64.

[mateoatr]

Some work items based on the approved design:

• Agree on the path format for the architecture-specific default install locations.
• Embed the default install location for each different architecture into the apphost.
• Add a mechanism into the apphost to retrieve the OS architecture in which the process is running.
• Extend the global install location config file (macOS and Linux)
  • Add support for downlevel apphost compat: installers should keep the first line of the config file as is, while adding architecture-specific lines.
  • Add logic for picking up the correct installation (search for the arch-prefixed line matching the current architecture and fallback to the non-prefixed line if none was found).
• Modify apphost to pick the correct arch-specific DOTNET_ROOT_ARCH env variable first and fallback to the default DOTNET_ROOT if it wasn't found.

[agocke]

LGTM -- @mateoatr feel free to add this information to the issue directly and change it how you like.

[vitek-karas]

Looks good - couple of test ideas:

• As we discussed develop a way to mock the "OS architecture" so that we can test this on any OS ideally.
• Extend the Windows tests to cover ARM64 (it should work already, but we probably don't have any test coverage)
• Validate that 3.1 apphost correctly picks up the default location even if the config file contains architecture specific lines in it

[agocke]

Closing as complete. We can track individual items separately if we still feel they're useful.