`dnx` dispatcher script fails when invoked via the `/usr/bin/dnx` symlink

[mthalman]

Summary

The dnx dispatcher at src/Layout/redist/dnx computes paths from $(dirname "$0"). In POSIX sh, $0 is the path used to invoke the script — symlinks are not followed. When invoked via /usr/bin/dnx (the standard Linux/macOS package symlink), the script looks for the SDK at /usr/bin/sdk/<ver>/dotnet.dll instead of /usr/share/dotnet/sdk/<ver>/dotnet.dll.

Regression introduced by #54472.

Repro

$ /usr/share/dotnet/dnx --help   # direct — works
…dispatches into the SDK…

$ dnx --help                     # via /usr/bin/dnx — fails
The application to execute does not exist: '/usr/bin/sdk/<ver>/dotnet.dll'

[lbussell]

This is also breaking .NET container image tests in the latest version of preview 6: dotnet/dotnet-docker#7240

The exact output is...

Failed to run docker run --name 11.0-dnx-134256588550726077 --rm  mcr.microsoft.com/dotnet/nightly/sdk:11.0-preview-resolute-amd64 dnx --help
Exit code: 129
Standard Error: The application to execute does not exist: '/usr/bin/sdk/11.0.100-preview.6.26310.110/dotnet.dll'

[mthalman]

Fix for Preview 6 will be coming in via dotnet/runtime#129258. dnx script is being moved to runtime's dotnet-host package.

[lbussell]

Fix for Preview 6 will be coming in via dotnet/runtime#129258. dnx script is being moved to runtime's dotnet-host package.

Separately, just to clarify, this doesn't address #49796, since the runtime will still dispatch the dnx call to the SDK, right? It just decouples dnx from the SDK so that it can dynamically choose which SDK to use.

[mthalman]

Fix for Preview 6 will be coming in via dotnet/runtime#129258. dnx script is being moved to runtime's dotnet-host package.

Separately, just to clarify, this doesn't address #49796, since the runtime will still dispatch the dnx call to the SDK, right? It just decouples dnx from the SDK so that it can dynamically choose which SDK to use.

It does both. It moves the script and fixes the symlink issue.