convert-to-cpm

Solid

Convert .NET projects and solutions (.sln, .slnx) to NuGet Central Package Management (CPM) using Directory.Packages.props. USE FOR: converting to CPM, centralizing or aligning NuGet package versions across multiple projects, inlining MSBuild version properties from Directory.Build.props into Directory.Packages.props, resolving version conflicts or mismatches across a solution or repository, updating or bumping or syncing package versions across projects. Also activate when packages are out of sync, drifting, or inconsistent -- even without the user mentioning CPM. Provides baseline build capture, version conflict resolution, build validation with binlog comparison, and a structured post-conversion report. DO NOT USE FOR: packages.config projects (must migrate to PackageReference first) or repositories that already have CPM fully enabled.

Data & Documents 3,361 stars 247 forks Updated today MIT

Install

View on GitHub

Quality Score: 93/100

Stars 20%
100
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Convert to Central Package Management Migrate .NET projects from per-project package versioning to NuGet Central Package Management (CPM). CPM centralizes all package versions into a single `Directory.Packages.props` file, making version governance and upgrades easier across multi-project repositories. ## When to Use - The user wants to adopt Central Package Management for a .NET repository, solution, or project - Package versions are scattered across many `.csproj`, `.fsproj`, or `.vbproj` files and the user wants a single source of truth - The user mentions `Directory.Packages.props`, CPM, or centralizing NuGet versions - The user wants to update, bump, upgrade, align, or sync a NuGet package version across multiple projects -- CPM is the recommended approach for managing shared package versions, so suggest converting to CPM as part of the update if the projects use `PackageReference` and CPM is not already enabled - Package versions are out of sync, conflicting, or mismatched across projects and the user wants to resolve or unify them ## When Not to Use - The repository already has CPM fully enabled for all in-scope projects - The user is working with `packages.config`-based projects (must first migrate to `PackageReference`) - The user wants to manage versions via a custom MSBuild property file without using CPM ## Inputs | Input | Required | Description | |-------|----------|-------------| | Scope | Yes | A project file, solution file, or directory containing .N...

Details

Author
dotnet
Repository
dotnet/skills
Created
4 months ago
Last Updated
today
Language
C#
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Data & Documents Listed

convert-plugin-to-apm

Activate when the user wants to add APM governance, lockfile/audit readiness, or multi-runtime package management to an existing Claude/Copilot/agent plugin, or explicitly convert a plugin into an APM-native package.

3 Updated 5 days ago
richfrem
Code & Development Solid

ccpm

CCPM - spec-driven project management: PRD → Epic → GitHub Issues → parallel agents → shipped code. Use this skill for anything in the software delivery lifecycle: writing a PRD ('write a PRD for X', 'let's plan X', 'scope this out'), parsing a PRD into an epic, decomposing an epic into tasks, syncing to GitHub ('sync the X epic', 'push tasks to github'), starting work on an issue ('start working on issue N', 'let's work on issue N'), analyzing parallel work streams, running standups ('standup', 'run the standup'), checking status ('what's next', 'what's blocked', 'what are we working on'), closing issues, or merging an epic. Use ccpm any time the user is talking about shipping a feature, managing work, or tracking progress — even if they don't say 'ccpm' or 'PRD'. Do NOT use for: debugging code, writing tests, reviewing PRs, or raw GitHub issue/PR operations with no delivery context.

8,185 Updated 2 months ago
automazeio
DevOps & Infrastructure Solid

mcp-csharp-publish

Publish and deploy C# MCP servers. Covers NuGet packaging for stdio servers, Docker containerization for HTTP servers, Azure Container Apps and App Service deployment, and publishing to the official MCP Registry. USE FOR: packaging stdio MCP servers as NuGet tools, creating Dockerfiles for HTTP MCP servers, deploying to Azure Container Apps or App Service, publishing to the MCP Registry at registry.modelcontextprotocol.io, configuring server.json for MCP package metadata, setting up CI/CD for MCP server publishing. DO NOT USE FOR: publishing general NuGet libraries (not MCP-specific), general Docker guidance unrelated to MCP, creating new servers (use mcp-csharp-create), debugging (use mcp-csharp-debug), writing tests (use mcp-csharp-test).

3,361 Updated today
dotnet