[Breaking Change] X86 version of .NET host will not be added to PATH on 64-bit Windows platforms

[NikolaMilosavljevic]

[Breaking Change] 32-bit .NET host will not be added to PATH on 64-bit Windows platforms

We are modifying the code in x86 version of .NET Windows Installers, that adds x86 host location to the PATH - Program Files (x86)\dotnet. Going forward, x86 host path will not be added on 64-bit Windows systems.

See pending PR for the actual change in .NET 7: #69902

This will be backported, and will affect, .NET 6 and .NET Core 3.1, as well.

Goal

This change streamlines .NET host experience on Windows 64-bit systems. Only 64-bit hosts will be available in system PATH - x64 host on x64 system and arm64 host on arm64 systems.

As a result, we remove the ambiguity of order of .NET hosts in system PATH - only one host will be in the PATH.

Existing Behavior

Currently, x86 host will be added to PATH, even on x64/arm64 systems. Depending on which .NET architecture installer is run first, user's machine could have either native (x64/arm64) or x86 host as first in the PATH list.

This presents problems with initial .NET installation, and gets further complicated during .NET servicing events. Any of these installation scenarios could modify the order of .NET hosts in PATH.

The experience is non-deterministic, and has a high chance of regressing user's .NET runtime experience.

Breaking Change

Going forward, x86 host location will only be added to the PATH on x86 systems.

Customers that need x86 host in the PATH on x64/arm64 systems need to add it to PATH manually.

This will affect .NET Core 3.1, .NET 6, .NET 7, and future versions.

Feedback

We would love your feedback.

[NikolaMilosavljevic]

cc @richlander @joeloff

[NikolaMilosavljevic]

@dotnet/compat

[richlander]

What was the tradeoff thinking on the backport?

I haven't written docs yet on this whole topic. I should do that as part of this change. Hold me to it.

[NikolaMilosavljevic]

What was the tradeoff thinking on the backport?

I haven't written docs yet on this whole topic. I should do that as part of this change. Hold me to it.

Backporting this to 6.0 would ensure parity with what was done for x64 installers on arm64 systems. Only native installer adds host location to the PATH. That change was backported to 6.0, 5.0 and 3.1, but 5.0 and 3.1 might not be interesting anymore.

I believe backport would also help with apps chaining .NET installers.

@joeloff @ericstj do you agree that this fix should be backported to 6.0?

[joeloff]

Definitely. It's been a source of pain for us in VS. We just had a P0 issue that came in for VS and given that 6.0 is LTS, if we don't fix it in 6.0 and 3.1, the problem will persist when we have VS and standalone installs.

[NikolaMilosavljevic]

Definitely. It's been a source of pain for us in VS. We just had a P0 issue that came in for VS and given that 6.0 is LTS, if we don't fix it in 6.0 and 3.1, the problem will persist when we have VS and standalone installs.

Considering that 3.1 is in support until end of this year, it makes sense to include it in backport plan. Will update the issue description.

[richlander]

Sounds good. Not pushback on my side but since this change is impactful, it is very important that we have very good clarity on this one. As you know, I'm very much a proponent of this approach.

[NikolaMilosavljevic]

It appears that this issue, and associated PR (#69902) were given sufficient time for feedback. @richlander any objections to merging now and proceeding with backports?

[richlander]

Works for me.

[NikolaMilosavljevic]

Doc issue created: dotnet/docs#29740

[ericstj]

Make sure you thoroughly test the backport. Examine the upgrade scenarios both through the installers and through VS. We have a history of missing scenarios here.

We also previously had apprehension making this change late in 6.0 (RC1, IIRC) as it was breaking. It's only gotten more breaking to do this in servicing since it will now happen with Microsoft Update, so be prepared with the breaking change notification and let folks know what to do about that.

[NikolaMilosavljevic]

Testing scenarios and results. All scenarios, and every step of every scenario, produced expected results.

Installer version	Description	Experience
3.1.25	official runtime	x86 installer adds host to PATH on all platforms
3.1.26	private runtime	x86 installer adds host to PATH on 32-bit systems only
6.0.5 SDK	official SDK	x86 installer adds host to PATH on all platforms
6.0.5	official runtime	x86 installer adds host to PATH on all platforms
6.0.6	private runtime	x86 installer adds host to PATH on 32-bit systems only
7.0	private runtime	x86 installer adds host to PATH on 32-bit systems only

Scenario 1 - x86 host should not be in PATH:

Step	Result
6.0.5 - x86	X86 in path
6.0.5 - amd64	Both in path, x86 is first
6.0.6 - x86	X64 in path - no x86
6.0.6 - amd64	X64 in path - no x86
Uninstall 6.0.6 - x86	X64 in path - no x86

Scenario 2 - x86 host should not be in PATH:

Step	Result
6.0.5 - x86	X86 in path
6.0.5 - amd64	Both in path, x86 is first
6.0.6 - amd64	Both in path, x86 is first
6.0.6 - x86	X64 in path - no x86

Scenario 3 - x86 host should not be in PATH:

Step	Result
6.0.5 - amd64	X64 in path
6.0.5 - x86	Both in path, x64 is first
6.0.6 - x86	X64 in path - no x86
6.0.6 - amd64	X64 in path - no x86

Scenario 4 - x86 host should not be in PATH:

Step	Result
6.0.5 - amd64	X64 in path
6.0.5 - x86	Both in path, x64 is first
6.0.6 - amd64	Both in path, x64 is first
6.0.6 - x86	X64 in path - no x86

Scenario 5 - mix of old and new and different versions:

Step	Result
6.0.5 - x86	X86 in path
6.0.5 - amd64	Both in path, x86 is first
7.0 - x86	Both in path, x86 is first
7.0 - amd64	Both in path, x86 is first
6.0.6 - x86	X64 in path - no x86
6.0.6 - amd64	X64 in path - no x86

Scenario 5 - mix of old and new:

Step	Result
7.0 - x86	No dotnet in PATH
6.0.5 - x86	X86 in path
6.0.6 - x86	No dotnet in PATH

Scenario 6 - older version SDK not regressing the PATH:

Step	Result
7.0 - x86	No dotnet in PATH
7.0 - amd64	X64 in path - no x86
6.0.5 SDK - amd64	X64 in path - no x86
6.0.5 SDK - x86	Both in path, x64 is first

Scenario 7 - user adds x86 to PATH and it is preserved:

Step	Result
6.0.6 - x86	No dotnet in PATH
Add x86 host to the end of system PATH	X86 in path
7.0 - x86	X86 in path
7.0 - amd64	Both in path, x86 is first

Scenario 8 - x86 host should not be in PATH:

Step	Result
3.1.25 - x86	X86 in path
3.1.25 - amd64	Both in path, x86 is first
3.1.26 - amd64	Both in path, x86 is first
3.1.26 - x86	X64 in path - no x86

cc @richlander , @ericstj , @joeloff

[richlander]

What about the uninstall scenario? Does x86 appear in the path again if you uninstall the new builds?

[NikolaMilosavljevic]

What about the uninstall scenario? Does x86 appear in the path again if you uninstall the new builds?

.NET servicing releases use major upgrade behavior. Installation of new version removes the old one. There is always only one version of any major .NET release.

I.e., the following steps would leave the machine without any 6.0 runtime versions:

Install 6.0.5
Install 6.0.6 - would perform major upgrade
Uninstall 6.0.6 - no 6.0 is present anymore

As a consequence of major upgrade experience, removing a new version of the product would not bring back the x86 path, as it was not there at the very beginning.

I can expand the scenarios and add uninstallation steps.

[richlander]

Right. I forgot. All good. LGTM.

[NikolaMilosavljevic]

@ericstj @joeloff do you think there are some more scenarios that need to be covered?

[joeloff]

The scenarios look good. Did you just test with the MSIs or with the actual bundles? Since none of the new installers are placing it on the PATH, the only potential issue would be from older installers holding on to a shared component.

[NikolaMilosavljevic]

The scenarios look good. Did you just test with the MSIs or with the actual bundles? Since none of the new installers are placing it on the PATH, the only potential issue would be from older installers holding on to a shared component.

I used actual bundles for all tests. Are there interesting tests with direct MSI install/upgrade?

[joeloff]

No, the bundles would be the more interesting ones because of how MSIs are reference counted.