Skip to content

[release/10.0.3xx] Update the dnx script to use the newest SDK - #54587

Merged
JoeRobich merged 5 commits into
release/10.0.3xxfrom
backport/pr-54472-to-release/10.0.3xx
Jun 4, 2026
Merged

[release/10.0.3xx] Update the dnx script to use the newest SDK#54587
JoeRobich merged 5 commits into
release/10.0.3xxfrom
backport/pr-54472-to-release/10.0.3xx

Conversation

@github-actions

@github-actions github-actions Bot commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Backport of #54472 to release/10.0.3xx

/cc @JoeRobich

Tactics

Summary

The dnx shell/batch scripts were invoking dotnet dnx, which respects any global.json in the working directory. If global.json pins an older SDK (pre-.NET 10) that doesn't support the dnx/tool execute command, users get a confusing "Unrecognized command or argument 'execute'" error. The fix changes both dnx and dnx.cmd to use dotnet --list-sdks to find the newest installed SDK, then directly invokes dotnet exec <sdk-path>/dotnet.dll dnx, bypassing global.json entirely. This is a safe, targeted fix appropriate for servicing because it only changes the launcher scripts and does not affect SDK internals.

Customer Impact

Users running dnx (or dotnet tool execute) in a directory containing a global.json that pins an SDK older than .NET 10 receive an unhelpful error: Unrecognized command or argument 'execute'. This affects all .NET 10 SDK users who work in repositories or directories with a global.json pointing to an older SDK version. The workaround is to run dnx from a directory without such a global.json, which is unintuitive. The issue affects .NET 10.0.3xx (this backport) and main (addressed by #54472).

Regression?

No — this is not a regression introduced by a specific PR. The dnx script was always susceptible to global.json version pinning since its initial introduction, because it relied on the SDK muxer which respects global.json. The bug is a design limitation documented in issue #51085.

Testing

Risk

Low. The change is confined to two small shell scripts (dnx and dnx.cmd) with no impact on SDK internals, MSBuild targets, or C# code. The logic is simple: enumerate installed SDKs, take the last (newest) one, and invoke it directly. The only edge case is a machine with no SDK installed, which would already fail before this change. Test coverage is via CI and manual validation.

JoeRobich and others added 5 commits June 3, 2026 22:33
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
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Joey Robichaud <joseph.robichaud@microsoft.com>
@github-actions github-actions Bot added the backport PR that has been backported to a servicing branch label Jun 3, 2026
@JoeRobich

Copy link
Copy Markdown
Member

/tactics

@JoeRobich
JoeRobich merged commit d42aa0d into release/10.0.3xx Jun 4, 2026
24 checks passed
@JoeRobich
JoeRobich deleted the backport/pr-54472-to-release/10.0.3xx branch June 4, 2026 19:01
@dotnet-milestone-bot dotnet-milestone-bot Bot added this to the 11.0-preview6 milestone Jun 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport PR that has been backported to a servicing branch Servicing-approved

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant