Add debug configuration for script command-line arguments (#4671)

[darlingtonogbuefi]

PR Summary

Adds the PowerShell: Launch Current File w/Args Prompt debug configuration snippet.

PR Checklist

Note: Tick the boxes below that apply to this pull request by putting an x between the square brackets.
Please mark anything not applicable to this PR NA.

• PR has a meaningful title
• Summarized changes
• PR has tests
• This PR is ready to merge and is not work in progress
  • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready

[Copilot]

Pull request overview

Adds a debug configuration snippet that prompts for PowerShell script arguments.

Changes:

• Adds a “Launch Current File w/Args Prompt” snippet using SpecifyScriptArgs.

---

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

[charris0559]

Yes. The failure in your screenshot is exactly the kind of CI failure you can hedge against, but you want to hedge against the class of failure, not just this one error.

The important lines are:

• Central Directory corrupt
• Invalid argument while reading ~/.nuget/packages/microsoft.aspnetcore.app.ref/8.0.30/...

That strongly points to a corrupted or partially restored NuGet package/cache on the GitHub runner, rather than necessarily bad application source code.

I would add a Dependency Integrity Shield around the build that:

• verifies caches before trusting them
• retries restore once from a clean state when corruption indicators appear
• clears the local NuGet cache on known corruption errors
• pins the .NET SDK and uses locked-mode restore where practical
• runs dotnet build / dotnet publish with --no-restore
• uploads restore logs and diagnostics with if: always()

I would also distinguish:

• our source failure
• our dependency failure
• runner/cache failure
• upstream dependency failure
• external service failure

For this screenshot, the first remediation I would attempt is: clear NuGet caches -> fresh restore -> publish with --no-restore, not a source-code change.

[charris0559]

This looks more like a transient macOS runner or NuGet cache failure than a source regression. The Central Directory corrupt and Invalid argument errors occur while reading microsoft.aspnetcore.app.ref/8.0.30. I’d recommend clearing the NuGet caches, doing one clean dotnet restore, and retrying dotnet publish --no-restore. If the clean retry still fails, preserve the logs and treat it as a non-transient dependency or build issue.