Repository navigation
docs: add notes for running on .NET 11 - #203
carldebilly wants to merge 2 commits into
Conversation
A new page, docs/dotnet-11.md, records what was checked with the .NET SDK 11.0.100: C# 15 by default for net11.0 and union results; FORCE_COLOR in the console logger, which Repl matches, and Console.ForegroundColor, which writes no colour to a redirected stream; dotnet watch, which leaves the streams attached but keeps the keyboard, so the interactive loop belongs to dotnet run; dotnet run -e; and dotnetup per-user installs, where an agent host outside the user's shell finds neither dotnet nor dnx, with three working configurations. The README, docs/for-coding-agents.md and the MCP publishing section link to it. A test pins that shell completion recognises a dotnet installed in a dotnetup folder, since it compares file names only. Closes #182.
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
autocarl
left a comment
autocarl
left a comment
There was a problem hiding this comment.
Changes requested on exact head 219d6a6, base/merge-base 0c9e0af. One introduced P2 documentation claim confirmed by real PowerShell execution with direct-bridge and apphost positive controls; see inline. Independent read-only review covered all five changed files. No product-source changes made.
Validation: warning-as-error Release unit-test project/dependency build passed after correcting the diagnostic clones local origin URL for SourceLink (initial build failed on that review-environment issue); 8 host-validator tests per target passed on net10.0 and net11.0, 16 total, no failures/skips. SDK 11.0.100 Linux probes reproduced default-language union compilation (net10 control rejected the same declaration), dotnet run -e environment propagation, logger FORCE_COLOR nonempty/0/NO_COLOR precedence and no redirected ForegroundColor escapes. Real PTY run delivered 10/10 keys; watch and watch --non-interactive delivered 0/10, all with nonredirected standard streams. New local Markdown targets/anchors checked. Applicable CI rechecked green before publication. Windows observations and isolated dotnetup runtime discovery were not independently rerun locally; installer access-mode guidance was cross-checked against official documentation. No full-solution local rebuild.
Separate scope note: PR explicitly defers the matching repl-website page, while #182 requires it. Track that follow-up before considering the whole issue complete; not treated as an introduced code defect here.
| Setting up shell completion works with a dotnetup `dotnet`: the setup check compares executable file names, | ||
| not folders. For an application started through `dotnet` rather than its own executable, PowerShell | ||
| completion keeps the full path of the `dotnet` that ran the setup, and stops answering if `dotnet` later | ||
| resolves to another installation; run the setup again after switching. |
There was a problem hiding this comment.
[P2] Do not promise working PowerShell completion for a DLL launched through dotnet
This paragraph presents completion as working with the original dotnet and needing setup again only after switching installations, but the generated completer already fails before any switch. The new test establishes validator acceptance, not operational completion.
Reproduced on Linux with PowerShell using Repl.Core from this exact checkout and the unmodified BuildManagedBlock output: a tiny app maps alpha; the direct dotnet Probe.dll completion __complete bridge returns alpha. Registering the block generated while launched via dotnet Probe.dll, then calling CommandCompletion.CompleteInput on dotnet al, instead returns dotnet diagnostic text (dotnet-completion does not exist), not alpha. Completing Probe al returns nothing. Generating the block via the very same applications own apphost makes Probe al return alpha. No installation was switched.
The generated block pins Environment.ProcessPath to dotnet, but invokes $invokedCommand completion __complete without the application DLL. The registered app name instead resolves to the apphost and fails the pinned-dotnet path comparison. Rerunning setup against another SDK cannot fix either issue. This runtime limitation predates the PR; the introduced defect is the new guidance claiming that this launch mode works. Please narrow the paragraph to host-validator acceptance and recommend the applications own executable/apphost for functional completion, or fix and end-to-end test the managed-host invocation before documenting it as supported.
There was a problem hiding this comment.
Fixed in 93e76e8. The .NET 11 page no longer claims this launch mode works. It now says completion does not depend on where .NET is installed and points to Shell Completion. docs/shell-completion.md ("User commands") replaces the "must match the app binary" line. It says to run setup from the app's own executable, and describes a setup started as dotnet myapp.dll: it is accepted, but the PowerShell block registers for dotnet as well as myapp (BuildPowerShellCompletionCommandNames adds the process file name and path) and runs dotnet completion __complete without the DLL. The repair is myapp completion install --shell powershell --force from the executable, then a new shell (same app id, so the block is replaced). The adapter defect itself predates this PR and is not fixed here.
A completion setup started as `dotnet myapp.dll` does not give working PowerShell completion: the generated completer is registered for dotnet as well as the app and runs `dotnet completion __complete` without the DLL. The .NET 11 page no longer says it works; docs/shell-completion.md now says to set completion up from the app's own executable, what a setup through dotnet does, and how to repair it. The dotnetup section pins the dnx package version, since dnx without one resolves the newest version when the server starts, and the MCP reference does the same. It wraps the JSON entries in mcpServers, gives the Windows value for each entry, the self-contained publish command, and the second cause of the launch error: a tool built for an older major runtime, with --allow-roll-forward for dnx and DOTNET_ROLL_FORWARD=Major for a global tool, both checked in the SDK 11 container. The access modes are attributed to the dotnetup documentation, and a host that sees another installation is covered.
Closes #182.
Adds
docs/dotnet-11.md("Running on .NET 11"), linked from the README, fromdocs/for-coding-agents.md(under the MCP client configuration and in the reading list) and from the MCP publishing section, whosednxexample now pins the package version.docs/shell-completion.mdcorrects how completion setup behaves when started throughdotnet. A test pins that shell completion setup accepts adotnetliving in a dotnetup folder.Observations (SDK 11.0.100)
Probes live outside the repo; Linux checks ran in
mcr.microsoft.com/dotnet/sdk:11.0, withscript -qecto give the process a pseudo-terminal.C# 15.
public union U(int, string);compiles and runs in anet11.0project with the default language version; the same file fails innet10.0(CS0106, CS1001).FORCE_COLOR.
Microsoft.Extensions.Logging.Console11.0.0,AddSimpleConsole(), stdout redirected (Linux): no SGR without the variable; SGR withFORCE_COLOR=1,FORCE_COLOR=0, andFORCE_COLOR=1 NO_COLOR=1. On a terminal,NO_COLOR=1removes the colour andNO_COLOR=1 FORCE_COLOR=1restores it. Source:ConsoleUtils.GetColorOverrideFromEnvironmentonrelease/11.0.Console.ForegroundColor+Console.Writewith stdout redirected: no escape bytes for any combination ofFORCE_COLOR/NO_COLOR, on Windows and on Linux.dotnet watch.
dotnet watch runreports stdin/stdout/stderr not redirected andDOTNET_WATCH=1, in a real Windows console (Start-Process) and under a Linux PTY.abcdefghijwritten to the terminal while the app'sConsole.ReadKeyloop was running: 0 keys received underdotnet watch run, 0 underdotnet watch --non-interactive run; 10/10 underdotnet run.dotnet-watch'sPhysicalConsoleruns its ownConsole.ReadKey(intercept: true)loop when stdin is not redirected (release/11.0.1xx).dotnet run -e.
dotnet run -e PROBE_VALUE=from-ereaches the app on Windows and Linux.dotnetup 0.3.0-preview.1.
dotnetup dotnetwith nothing installed:%LOCALAPPDATA%\dotnetup\dotnet(Windows),~/.local/share/dotnetup/dotnet(Linux). Access modes and defaults from learn.microsoft.com (public preview).dotnetup install 11.0 --untracked --install-path <dir>leaves userPATHandDOTNET_ROOTunchanged; with aPATHholding nodotnet,where dotnet/where dnxfind nothing;<dir>\dotnet.exe dnx --helpand<dir>\dnx.cmd --helpwork. dotnetup was removed afterwards./usr/share/dotnetmoved away):dotnetanddnxnot onPATH;<root>/dotnet dnx -y ToolProbe --add-source <local feed> -- mcp serveruns the tool withoutDOTNET_ROOT; the installed global-tool shim fails with "You must install .NET to run this application" and runs withDOTNET_ROOT=<root>; a published framework-dependent apphost behaves the same.dnx (SDK 11 container, only runtime 11.0.0).
dnxacceptsId@version; on a first run it writes nothing to stdout but the tool's own output. Anet10.0tool exits 150 with "You must install or update .NET to run this application"; it runs on 11.0.0 withdnx -y --allow-roll-forward Id@version, and as a global tool withDOTNET_ROLL_FORWARD=Major.dnx -yalso parses on SDK 10.0.404.dotnet publish -c Release -r linux-x64 --self-containedworks on aPackAsToolproject, and the output runs with no .NET installed.Shell completion.
ShellCompletionHostValidatorcompares file names only; the new test uses dotnetup host paths. A setup started asdotnet myapp.dllwrites a PowerShell completer registered fordotnetas well as the app, which runsdotnet completion __completewithout the DLL (reproduced by the review).docs/shell-completion.mdnow says to set up from the app's own executable and how to repair such a setup; the adapter defect predates this PR and is not fixed here.Not in this PR
The matching page on
yllibed/repl-website(hand-written pages), which the issue asks for.