[release/10.0] Revert conditionally setting SYSTEM PATH in host install (#118092)

[github-actions]

Backport of #120472 to release/10.0

#118092 causes the path to dotnet.exe to be removed from PATH even when there are previous installs. For a repro, (1) install .NET 9.0, (2) install .NET 10 RC1, (3) uninstall .NET 10 RC1. The path to dotnet.exe will be removed from PATH even though .NET 9.0 is still installed. This PR reverts that change.

Note that WiX 5 changes also touches the affected file(s), and those also separately cause this bug. Both need to be fixed for this bug to be considered fixed. That fix is here: dotnet/dotnet#2794.

/cc @PranavSenthilnathan @joeloff

Customer Impact

• Customer reported
• Found internally

Repro:

1. install .NET 9.0
2. install .NET 10 RC1
3. uninstall .NET 10 RC1

Expected: dotnet still on the path
Actual: dotnet removed from the path

Regression

• Yes
• No

This regression was introduced in a previous preview in #118092.

Testing

The scenario was caught by manual validation of RC2 (https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2582340). The fix was verified manually.

Risk

Low. Revert to previous known working state.

[artl93]

@jeffhandley and @PranavSenthilnathan - do we have a potential testing gap here that we might want to dig into deeper?

[PranavSenthilnathan]

This was caught by CTI validation which seems reasonable - I'm just a bit surprised that it took until RC2 validation since RC1 already had the issue. We could also invest in automated tests. @joeloff do you have automated tests for the SDK bundles?

[joeloff]

We do not have automated setup tests. This specific issue requires testing SxS scenarios where both .NET the 9.0 and 10 runtimes are installed. All our setup testing for .NET has been manual. For any automated testing we need to use clean machines.

[jeffhandley]

Applied Servicing-approved Approved for servicing release . Required setup fix treated as tell mode.

[artl93]

This was caught by CTI validation which seems reasonable - I'm just a bit surprised that it took until RC2 validation since RC1 already had the issue. We could also invest in automated tests. @joeloff do you have automated tests for the SDK bundles?

This is my concern - should we take a more focused eye to this area, since this did take while to find this corner?

[PranavSenthilnathan]

RC2 had more thorough testing because it was the first release where runtime+sdk+aspnetcore components were all WiX 5. @joeloff and @balachir worked on adding this manual test coverage. So it's possible that RC1 didn't have the same coverage.

[artl93]

RC2 had more thorough testing because it was the first release where runtime+sdk+aspnetcore components were all WiX 5. @joeloff and @balachir worked on adding this manual test coverage. So it's possible that RC1 didn't have the same coverage.

Put another way: How much testing have we done with V9-> V10 RC2 -> Remove RC2
Basically, how do we guarantee that someone can get their box back into operable state if there were a problem?

[joeloff]

RC2 had more thorough testing because it was the first release where runtime+sdk+aspnetcore components were all WiX 5. @joeloff and @balachir worked on adding this manual test coverage. So it's possible that RC1 didn't have the same coverage.

Put another way: How much testing have we done with V9-> V10 RC2 -> Remove RC2 Basically, how do we guarantee that someone can get their box back into operable state if there were a problem?

They only need to repair the older install or VS, depending on how they acquired the other version of .NET. Thus far I've only had one external report through VS and that customer's issue is now resolved.

[PranavSenthilnathan]

Installing net 10.0 again also fixes the issue (e.g. if someone uninstalls 10 RC1 and then installs 10 RC2).