dotnet-tool-publishing

Package and publish .NET CLI tools to NuGet with verified build, pack, and push workflows.

2|Updated Jul 18, 2026
One-click install
npx skills add https://github.com/Arasz/ai-badger --skill dotnet-tool-publishing-arasz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dotnet-tool-publishing
Source: https://github.com/Arasz/ai-badger/tree/main/features/dotnet/skills/dotnet-workload/references/dotnet-tool-publishing
Command: npx skills add https://github.com/Arasz/ai-badger --skill dotnet-tool-publishing-arasz

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Publishing a PackAsTool .NET CLI tool to NuGet fails in non-obvious ways: MSB3030 errors on clean checkouts, multi-RID shell races that install the wrong platform payload, gitignored bundled assets silently missing from the nupkg, and green workflow runs that pushed nothing due to 409 conflicts. This Skill encodes measured fixes for each trap so a publish succeeds on the first real attempt. ## Core Features & Use Cases - Build-before-pack ordering: Diagnoses the MSB3030 clean-checkout failure and its Web-SDK multi-RID inversion, where a single pack without --no-build is the correct form. - Multi-RID matrix publishing: Covers per-RID pack jobs, the shell-race fix via a self-gating patch script, --skip-duplicate requirements, and payload-before-shell push ordering. - Trusted Publishing setup: Configures NuGet OIDC login with environment approval gates, id-token permissions, and workflow file name policy binding. - Fresh-install verification: Runs an isolated install gate with sha256 asset integrity checks, MCP stdio protocol round trips, and silent-degradation detection for bundled models. - Use Case: You are shipping a .NET 10 global tool with six runtime identifiers and a bundled ONNX model. Use this Skill to write the publish workflow, avoid the shell race, verify the packed assets, and confirm a clean install works before announcing the release. ## Quick Start Use the dotnet-tool-publishing skill to create a Trusted Publishing workflow for my PackAsTool project and verify the packed nupkg before pushing to NuGet.

Frequently Asked Questions about dotnet-tool-publishing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I publish a .NET CLI tool to NuGet with GitHub Actions?

Build first with dotnet build -c Release, then pack with dotnet pack --no-build, and push via NuGet/login@v1 using Trusted Publishing OIDC. The workflow needs id-token: write permission and the nuget.org policy must match the workflow file name exactly.

Why does dotnet pack fail with MSB3030 on a clean checkout?

The publish pass inside pack expects bin/Release outputs the implicit build never produced. Run dotnet build -c Release before dotnet pack --no-build. For Web-SDK multi-RID projects the advice inverts: use a single pack without --no-build.

How do I set up NuGet Trusted Publishing without API keys?

Create a Trusted Publishing policy on nuget.org bound to the package owner, repository, and workflow file name. In the workflow set permissions id-token: write, use NuGet/login@v1 with your nuget.org username, then push with the temporary key from the login step output.

Why does my multi-RID dotnet tool install fail on some platforms?

Each matrix pack job emits its own shell package listing only its own RID, and --skip-duplicate keeps whichever pushes first. Fix it by post-processing every job's shell with a patch script that rewrites DotnetToolSettings.xml to the full RID list before upload.

Why did my publish workflow succeed but nothing was published?

With --skip-duplicate, every 409 conflict becomes a no-op and the run still exits green. Check the push-step log lines: 201 Created means published, Conflict means skipped. Persistent 409s across versions indicate a reserved namespace on the package id.

How do I verify a published dotnet tool works on a fresh install?

Install with --tool-path to a temp dir using a fresh NUGET_PACKAGES folder so the fetch genuinely hits nuget.org. Verify bundled assets by sha256 against source pins, capture CLI output from stderr, and drive an MCP stdio initialize round trip to prove the tool runs.