[Breaking change] Stop adding `C:\Program Files(x86)\dotnet` to the path on x64 and Arm64 machines

[richlander]

[Breaking change] Stop adding C:\Program Files(x86)\dotnet to the path on x64 and Arm64 machines

Proposal: .NET Installers only add the .NET global install location to the PATH if the architecture of the .NET build and machine match.

Examples:

• The x64 .NET build will add its location to the PATH when installed on an x64 machine/operating system.
• A 32-bit x86 .NET build will not add its location to the PATH when installed on that same machine.
• Order of installs does not matter.

Motivation for break:

• Adding multiple builds of .NET to the PATH is incoherent, results in bad UX, and is difficult to explain.
• We have already started down this direction with x64 on Arm64. It makes sense to make the product consistent, by repeating the pattern with x86 on x64 and x86 on Arm64.

Context

When you install .NET, the installer adds the install location to the PATH environment variable. This behavior is sound and enables the OS to find dotnet when you use it. We build multiple .NET for multiple architectures (x86, x64, ...). In some cases, an OS supports multiple architectures and then we need a plan for how multiple .NET locations in the PATH works. In short, it doesn't work well. Going forward, we should only ever add the OS native-architecture .NET install location to the PATH. We already started doing that on Apple M1 (Arm64) machines (we only add the Arm64 .NET to the PATH, not the x64 version). We need to repeat this pattern with Windows now, with the 32-bit .NET build.

Relevant: https://twitter.com/dotMorten/status/1448403460756361220.

UX for x86 32-bit installs

This change means that users that rely on the 32-bit builds (either exclusively or otherwise) may experience a regression in behavior. By default, the 32-bit dotnet will not be available. This is already the case for users who install both the 64-bit and 32-bit build on Windows x64 (possibly by virtue of installing Visual Studio). If users solely depend on the 32-bit runtime, then they probably won't see a regression in behavior. If they rely on the 32-bit SDK, then they will. We have already rationalized about this experience with x64 on Arm64. See the "Better x64 dotnet UX" section in Supporting .NET with x64 emulation on Arm64 for a discussion of how to approach a .NET build that is not available in the PATH by default.

[ericstj]

https://twitter.com/dotMorten/status/1448403460756361220

While related that's a different bug. You can't fix that bug by removing path from x86 in 7.0. You would have to go back and remove the x86 PATH entry from every version of dotnet that was ever shipped, and also fix the ref counting issue that would abandon the x86 PATH entry on uninstall.

We fixed the issue mentioned in that tweet already, and what I believe is the primary issue that caused folks to notice the x86 PATH entry at all, by fixing the reordering of PATH on upgrades.

The purpose of this issue is to change the product to prevent accidentally getting a non-native dotnet on the PATH from a clean install. That can happen today if you install x86 before x64 or ARM64. That is the reason we still want to do this even with the reordering fix.

[richlander]

This was resolved: dotnet/runtime#69902