-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
When you install dotnet with dotnetup, by default the version you installed should be the "active" version that you get from the command line when you type dotnet, or that is used by the IDE.
Some history: Some of our initial design is here. We were going to set a registry key that would prevent the admin install from updating the admin path. This was implemented, but we had to back it out for .NET 10 due to MSI upgrade issues.
Now, we think the best option to deal with admin installs may be to set environment variables that tell the admin installed muxer to redirect to the user install. That's captured here. However, we haven't settled on that as a design and even if we did it would probably not be ready for us to use for an initial public preview of dotnetup to gather feedback.
So, our current plans for that preview are:
- When there's an admin install on Windows, elevate and remove the Program Files dotnet path from the admin PATH value. This will provide a good experience, but the next update of the admin version of dotnet will reset the PATH to the Program Files version. Related: DNUP Path Manipulation on Windows #51124, dotnetup: Modify admin PATH on windows #52167
- Add a dotnetup command to switch to the user local or to the admin install version of the SDK. This can be used to fix the state after an admin install update.
- Update the PowerShell profile to put the user dotnet install root on the PATH before the admin one. This should by default on install as well as when the command is run to switch the default dotnet install root.
- Make dotnet up shadow dotnet commands #52122
- Handle path updates on Linux / Mac:
dotnetUpshould be able to modify user profile to configure path on Unix #51582
These actions should be taken (optionally) when dotnetup installs an SDK or runtime, and there should also be commands to do this manually. Straw man: dotnetup setinstallroot user and dotnetup setinstallroot admin.