MacOS x .NET SDK Installer Issue

[claudiaregio]

Describe the bug

I'm running user studies and am 2/2 on MacOS users running into the exact same issue. They tried installing the SDK and it required random additional code to be run in a terminal for the SDK to be found.

To Reproduce

1. User installed SDK from rightmost column here https://github.com/dotnet/dotnet/blob/main/docs/builds-table.md that matched their architecture
2. VS Code Insiders was already opened w/ integrated terminal opened
3. User ran dotnet --version -> got command not found: dotnet
4. Closed VSC Insiders
5. Reopened VSC Insiders
6. User ran dotnet --version again in VSC Insiders integrated terminal -> got command not found: dotnet
7. User ran dotnet --version again in external terminal -> got command not found: dotnet
8. User ran ln -s /usr/local/share/dotnet/dotnet /usr/local/bin/ from StackOverflow with 'sudo' in same external terminal
9. User ran dotnet --version in same external terminal -> Worked ✅ (no refresh, no new terminal, no new anything)

Further technical details

MacOS, zsh for both users

[nagilson]

I imagine this could be fixed by adding the symlink creation at this point: https://github.com/dotnet/runtime/blob/b79c4fbf284a6b002f46b1fc95ee39e545687515/src/installer/pkg/sfx/installers/osx_scripts/host/postinstall#L25

We should probably check if the symlink exists already and not create it if so to prevent breaking existing user scenarios.
We may also want to consider whether the symlink should be owned by root or the user from both a security perspective and a standards perspective.

The .NET Install Tool should also likely have special logic to handle this for installs made by unpatched / old installers.

[blowdart]

User ran random commands from stack overflow as root? 🤦

Who owns the directory where the symbolic link would be created?

What's the default permissions on the directory?

Would this affect all users on the machine?

[baronfel]

Homebrew has a much nicer experience here because brew itself has already added a bin-style directory to PATH, and it ensures that symlinks to the binary items in formula get a symlink into that directory. We're really trying to solve a last-mile problem here -path_helper updates don't take on shells that already exist, and several common zsh configurations end up nuking/undoing path_helper due to ordering. Both lead to a garbage user experience.

[nagilson]

@baronfel, You weren't able to reproduce with the above steps, correct? Namely, the part that says that matched their architecture. It sounds like when we reached back out, we determined they installed using a non-native architecture, which made it so the PATH was not set.

[baronfel]

Correct - for this specific report. I'm trying to sync with @claudiaregio offline about some of the other reports to see if there's a commonality or if there are more things to dig into.

[nagilson]

I think a lot of these are likely dotnet/vscode-csharp#8370