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

[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: https://github.com/dotnet/runtime/pull/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.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 1
  • Comments: 19 (19 by maintainers)

Most upvoted comments

Right. I forgot. All good. LGTM.

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.