-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Breaking Change] X86 version of .NET host will not be added to PATH on 64-bit Windows platforms #70039
Comments
@dotnet/compat |
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? |
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. |
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. |
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? |
Works for me. |
Doc issue created: dotnet/docs#29740 |
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. |
Testing scenarios and results. All scenarios, and every step of every scenario, produced expected results.
Scenario 1 - x86 host should not be in PATH:
Scenario 2 - x86 host should not be in PATH:
Scenario 3 - x86 host should not be in PATH:
Scenario 4 - x86 host should not be in PATH:
Scenario 5 - mix of old and new and different versions:
Scenario 5 - mix of old and new:
Scenario 6 - older version SDK not regressing the PATH:
Scenario 7 - user adds x86 to PATH and it is preserved:
Scenario 8 - x86 host should not be in PATH:
cc @richlander , @ericstj , @joeloff |
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 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. |
Right. I forgot. All good. LGTM. |
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? |
No, the bundles would be the more interesting ones because of how MSIs are reference counted. |
[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.
The text was updated successfully, but these errors were encountered: