Update the dnx script to use the newest SDK - #54472
Conversation
The dnx scripts worked by invoking `dotnet dnx`. This creates issues in folders where a global.json has pinned a version of the SDK which does not support the `dnx` command. We change the behavior of the scripts to use `dotnet--list-sdks` to get the list of installed SDKs. We then take the last entry, which should be the latest as the list is sorted. We then directly execute that version of the dotnet.dll. This allows the dnx script to script to work despite any global.json. Resolves #51085
There was a problem hiding this comment.
Pull request overview
Updates the dnx launch scripts so they bypass global.json SDK selection by locating the newest installed SDK and directly executing its dotnet.dll, addressing scenarios where dotnet dnx would be routed to an older SDK that lacks the required command.
Changes:
- Windows (
dnx.cmd): resolve latest SDK version viadotnet --list-sdks, thendotnet exec <sdk>\dotnet.dll tool exec .... - Unix (
dnx): resolve latest SDK version viadotnet --list-sdkspipeline, thendotnet exec <sdk>/dotnet.dll tool exec ....
Show a summary per file
| File | Description |
|---|---|
| src/Layout/redist/dnx.cmd | Switches from dotnet dnx to selecting a latest SDK and executing its dotnet.dll to avoid global.json pinning. |
| src/Layout/redist/dnx | Same behavior change as Windows script for Unix environments. |
Copilot's findings
- Files reviewed: 2/2 changed files
- Comments generated: 2
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Joey Robichaud <joseph.robichaud@microsoft.com>
|
Have you considered just making dnx into an apphost that has a relative pointer to a dnx dll that sits next to dotnet.dll to call into it directly? Then you would just be using standard apphost resolution. |
We've thought of using a NativeAOT app for the dnx shim. We want to avoid having files in the root that are tied to a specific SDK version, as it's hard to make sure it's the right version when installing or upgrading multiple SDKs. It sounds like an apphost with a relative pointer would be tied to a specific SDK version. What I'd prefer is a parameter we could pass to the dotnet executable that would tell it to ignore global.json, rather than these scripts having to find the latest SDK and invoke dotnet.dll directly. I think invoking dotnet.dll directly won't necessarily be the right thing as we're moving some functionality to AOT. |
@dsplaisted That was my initial plan. But it seems we do not want to make changes to the muxer or the corehost at this time.
Could we handle this by first looking for an executable in the SDK folder then falling back to dotnet.dll? |
| SDK_VERSION=$(DOTNET_MULTILEVEL_LOOKUP=0 "$DOTNET" --list-sdks | tail -1 | cut -d' ' -f1) | ||
| SDK_PATH="$(dirname "$0")/sdk/$SDK_VERSION/dotnet.dll" | ||
|
|
||
| DOTNET_MULTILEVEL_LOOKUP=0 "$DOTNET" exec "$SDK_PATH" tool exec "$@" No newline at end of file |
There was a problem hiding this comment.
we should not set MLL and should call dnx instead of tool exec
|
If there are no other options that work for 10 (which so far, we haven't come up with one), I think we're ok with this as a stopgap. The main concerns are that we didn't want to churn the dnx script as it's meant to be a singleton so any churn creates issues of "which one does the customer have" AND calling dotnet.dll doesn't work long-term as we hope eventually to move dnx into dotnet-aot.dll. |
dsplaisted
left a comment
dsplaisted
left a comment
There was a problem hiding this comment.
I'm not really qualified to review sh or powershell scripts, but I am OK with this approach overall.
|
@marcpopMSFT Am I good to start a backport of this to 10.0.4xx? |
|
/backport to release/10.0.3xx |
|
Started backporting to |
JoeRobich
added
the
breaking-change
|
Added When you commit this breaking change:
You can refer to the .NET SDK breaking change guidelines |
The earlier merge+revert on this branch left the dnx launch scripts at their pre-dotnet#54472 form, which would have reverted main's dnx simplification. Restore them to match upstream/main so this PR only changes dotnetup acquisition.
The dnx scripts worked by invoking
dotnet dnx. This creates issues in folders where a global.json has pinned a version of the SDK which does not support thednxcommand.We change the behavior of the scripts to use
dotnet--list-sdksto get the list of installed SDKs. We then take the last entry, which should be the latest as the list is sorted. We then directly execute that version of the dotnet.dll. This allows the dnx script to script to work despite any global.json.Resolves #51085