Surface dotnet new post-action output under --verbose for new command

[Zach Teutsch (zateutsch)]

Summary

Surfaces dotnet new post-creation action output (restore, package add, etc.) under --verbose for the winapp new command. Previously this output was buffered silently behind a spinner and only dumped after the command finished, which made dotnet new failures during scaffolding hard to diagnose.

Fixes #753.

Problem

The final scaffold step of winapp new runs dotnet new, whose post-creation actions (NuGet restore, package add, etc.) can fail. That output was captured behind a Spectre spinner and surfaced only after completion, so a user hitting a restore failure had no live insight into what dotnet was actually doing.

Change

• Under --verbose (Debug log level), the scaffold step now streams dotnet new's stdout/stderr live via logger.LogDebug, plus logs the invoked dotnet args and the exit code.
• The non-verbose path is unchanged: it keeps the spinner and existing buffered logging.
• Added optional onOutputLine / onErrorLine callbacks to the injection-safe ArgumentList overload of RunDotnetCommandAsync (and threaded them through RunDotnetProcessAsync). Output is still captured to buffers, so the failure-detail message (stderr ?? stdout) is preserved.

Why this approach

The scaffold needs both (a) the injection-safe ArgumentList form (args include a user-derived project name / output path) and (b) captured stdout/stderr for the failure detail. The existing RunDotnetStreamingAsync takes a raw string (not injection-safe) and returns no buffers, so adding tee-style callbacks to the buffered ArgumentList path was the smallest correct reuse.

Testing

• dotnet build clean (0 warnings / 0 errors).
• WinApp.Cli.Tests — 60/60 NewCommandHandlerTests pass, including 2 new tests:
  • Handler_Verbose_StreamsScaffoldPostActionOutput — verifies post-creation output streams live under --verbose.
  • Handler_ScaffoldFails_SurfacesPostActionErrorDetail — verifies the underlying dotnet error detail is surfaced on failure.

Docs

• Updated plugins/winapp/skills/winapp-setup/SKILL.md with a --verbose diagnose example and a troubleshooting row.
• No CLI grammar change, so docs/cli-schema.json, npm forwarding, and version.json are intentionally untouched.

Notes

• --verbose + --json remains a rejected conflict, so streamed Debug lines never pollute JSON output.
• dotnet new args continue to use ProcessStartInfo.ArgumentList; streamed lines are passed as a structured {Output} logging argument (no format-string/injection risk).

[github-actions]

Build Metrics Report

Binary Sizes

Artifact	Baseline	Current	Delta
CLI (ARM64)	38.62 MB	38.62 MB	📈 +1.5 KB (+0.00%)
CLI (x64)	38.74 MB	38.74 MB	📈 +1.5 KB (+0.00%)
MSIX (ARM64)	16.02 MB	16.02 MB	📈 +0.1 KB (+0.00%)
MSIX (x64)	17.02 MB	17.02 MB	📈 +1.5 KB (+0.01%)
NPM Package	33.42 MB	33.42 MB	📈 +2.3 KB (+0.01%)
NuGet Package	33.46 MB	33.46 MB	📈 +0.8 KB (+0.00%)

Test Results

✅ 4579 passed, 5 skipped out of 4584 tests in 575.3s (+3 tests, -38.5s vs. baseline)

Test Coverage

✅ 89.2% line coverage, 82.4% branch coverage · ✅ +0.1% vs. baseline

CLI Startup Time

51ms median (x64, winapp --version) · ✅ +5ms vs. baseline

Try This Build

Installs the MSIX for your architecture, replacing any previously installed build. Needs the GitHub CLI — the command offers to install it and sign you in if it is missing.

& ([scriptblock]::Create((irm https://raw.githubusercontent.com/microsoft/winappCli/main/scripts/winapp-pr.ps1))) 755

Switching between builds often?

Put the tool on your PATH once:

& ([scriptblock]::Create((irm https://raw.githubusercontent.com/microsoft/winappCli/main/scripts/winapp-pr.ps1))) -AddToPath

Then this build is just:

winapp-pr 755

Run winapp-pr with no arguments to pick from a list of open PRs.

---

Updated 2026-08-14 21:20:34 UTC · commit cda6afb · workflow run

[Copilot]

Pull request overview

Streams dotnet new post-action diagnostics during verbose scaffolding while preserving buffered failure details.

Changes:

• Adds live stdout/stderr callbacks to buffered dotnet execution.
• Uses callbacks for verbose winapp new scaffolding.
• Adds tests, fake-service support, and troubleshooting guidance.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
IDotNetService.cs	Defines optional line callbacks.
DotNetService.cs	Captures and forwards process output.
NewCommand.cs	Streams verbose scaffold diagnostics.
NewCommandHandlerTests.cs	Tests verbose output and failure details.
FakeDotNetService.cs	Replays buffered output through callbacks.
SKILL.md	Documents verbose troubleshooting.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.