dotnet-nuget-publish

Configures GitHub Actions workflows to publish .NET packages and tools to nuget.org.

2|Updated Aug 2, 2026
One-click install
npx skills add https://github.com/Arasz/ai-raccoon --skill dotnet-nuget-publish-arasz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dotnet-nuget-publish
Source: https://github.com/Arasz/ai-raccoon/tree/main/.ai-badger/skills/learned/uncategorized/dotnet-nuget-publish
Command: npx skills add https://github.com/Arasz/ai-raccoon --skill dotnet-nuget-publish-arasz

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Publishing a .NET library or PackAsTool global tool to nuget.org involves fragile CI wiring: OIDC trusted publishing policies, multi-RID pack matrices, version bumps spread across four files, and post-publish indexing lag that produces false install failures. This Skill encodes verified workflow skeletons and pitfalls so the publish pipeline works on the first dispatch. ## Core Features & Use Cases - Trusted Publishing setup: Configures GitHub Actions with OIDC (NuGet/login) instead of API keys, matching the nuget.org policy on workflow file name and environment, with manual approval via a required-reviewers environment on the push job only. - Multi-RID PackAsTool publishing: Builds before pack, pushes both the tool shell and per-RID payload packages, and uses --skip-duplicate to handle the shared shell across matrix jobs. - Version bump discipline: RED-first contract test update, then csproj (PackageVersion, InformationalVersion, AssemblyVersion), .mcp/server.json, and the fresh-install script pin. - Use Case: When asked to "add a publish workflow" to a .NET repo, generate build.yml, publish.yml, and nightly.yml, fix csproj pack metadata (license, tags, authors, repository URLs), and gate the release on a local fresh-install rehearsal before dispatch. ## Quick Start Set up a trusted-publishing GitHub Actions workflow to publish my .NET tool to nuget.org with manual approval and multi-RID packing.

Frequently Asked Questions about dotnet-nuget-publish

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

FAQPage Schema
How do I publish a .NET package to nuget.org from GitHub Actions?

Use a workflow_dispatch publish workflow with NuGet/login@v1 for OIDC trusted publishing, then dotnet nuget push with the login step's NUGET_API_KEY output and --skip-duplicate. The nuget.org policy must match the workflow file name and optional environment exactly.

How do I publish a multi-RID .NET global tool to NuGet?

Run a pack matrix with one job per RID: build with -p:RuntimeIdentifiers first, then dotnet pack --no-build. Push both the tool shell and every per-RID payload package, using --skip-duplicate since all matrix jobs emit the same shell id and version.

Why does dotnet tool install fail right after publishing to nuget.org?

The flatcontainer blob goes live within minutes but the registration endpoints lag 15-20 minutes or more, and the user-level NuGet http-cache serves stale registrations. Clear ~/.local/share/NuGet/http-cache and gate installs on the registration endpoint returning 200.

Why does dotnet pack fail with MSB3030 on a multi-RID project?

Packing an unbuilt multi-RID project fails in Microsoft.NET.Publish.targets. Run dotnet build -c Release with the RuntimeIdentifiers property before dotnet pack --no-build, or pack without --no-build.

Should I use NuGet API keys or trusted publishing in GitHub Actions?

Trusted publishing (OIDC) is preferred: the nuget.org policy is keyed to package owner, repo, workflow file name, and optional environment, with no long-lived secrets. Put only the push job under a required-reviewers environment for manual approval.

What metadata should a NuGet package csproj include?

Include PackageLicenseExpression matching the repo LICENSE, Authors as a display name, PackageProjectUrl, RepositoryUrl with RepositoryType=git, PackageReadmeFile, Description, and PackageTags written as terms users would search, never internal implementation details.