Power NuGet Manager

Manage NuGet packages across .NET solutions using the dotnet CLI with enforced verification, version safety, and automatic restore workflows.

When to Use This Command

Run this command when...

• You need to add, remove, or update NuGet packages across one or more .NET projects in a solution
• You want to verify that a specific package version exists on NuGet.org before applying changes
• You must update a package version in centralized Directory.Packages.props or per-project .csproj files safely
• You need a consistent workflow that prevents direct file edits for add/remove operations
• You want automatic dotnet restore validation after every version change to catch compatibility issues early

Quick Start

Copy
# .claude/commands/power-nuget-manager.yaml
name: Power NuGet Manager
description: Safely manage NuGet packages with verification and restore
inputs:
  - name: action
    description: "add, remove, or update"
  - name: package
    description: "NuGet package name"
  - name: version
    description: "Target version (for update)"
    default: ""

Copy
# Add a package to a specific project
claude "power-nuget-manager add Serilog --project src/WebApi/WebApi.csproj"

# Update a package version across the solution
claude "power-nuget-manager update Newtonsoft.Json --version 13.0.3"

Output:
  [verify] Checking NuGet for [email protected]... found
  [locate] Version managed in Directory.Packages.props
  [update] Updated Newtonsoft.Json 12.0.3 -> 13.0.3
  [restore] Running dotnet restore... success
  Done. 1 package updated, 0 errors.

Core Concepts

Concept	Description
CLI-First Rule	Always use dotnet add/remove package for additions and removals; never edit project files directly
Version Verification	Every version update begins by confirming the version exists on NuGet.org via dotnet package search
Centralized Management	Detects Directory.Packages.props for solution-wide version control vs per-project .csproj files
Restore Validation	Runs dotnet restore immediately after every change to catch dependency conflicts
Safe Rollback	Reverts changes automatically if dotnet restore fails after a version update

Workflow:
  ┌──────────────┐    ┌───────────────┐    ┌──────────────┐
  │ Verify NuGet │───>│ Locate Config │───>│ Apply Change │
  └──────────────┘    └───────────────┘    └──────┬───────┘
                                                  │
                                           ┌──────▼───────┐
                                           │ dotnet restore│
                                           └──────┬───────┘
                                          pass/   │   \fail
                                        ┌────┐    │   ┌──────┐
                                        │Done│    │   │Revert│
                                        └────┘    │   └──────┘

Configuration

Parameter	Type	Default	Description
action	string	required	Operation: add, remove, or update
package	string	required	NuGet package name (e.g., Newtonsoft.Json)
version	string	latest	Target version for add or update operations
project	string	solution	Specific .csproj path or entire solution
verify	boolean	true	Check NuGet.org before applying version changes

Best Practices

1. Always verify before updating -- Let the command confirm the version exists on NuGet.org rather than guessing version numbers. This prevents broken restores and wasted debugging time.
2. Prefer centralized version management -- Use Directory.Packages.props for solutions with multiple projects to keep all package versions in sync and avoid version drift.
3. Run on the full solution -- When updating shared packages, target the solution root so that all projects receive the change and dotnet restore validates cross-project compatibility.
4. Review restore output carefully -- A successful restore does not guarantee runtime compatibility. Check for binding redirect warnings and framework version conflicts in the output.
5. Commit after each package change -- Make atomic commits per package operation so that rollbacks are clean and git bisect remains effective for tracking regressions.

Common Issues

1. Version not found on NuGet -- The specified version does not exist or is unlisted. Run dotnet package search <name> --exact-match manually to see available versions. Check for prerelease versions with --prerelease flag.
2. Restore fails after update -- The new version has incompatible dependencies with other packages in the solution. Revert the change, then check the dependency graph with dotnet list package --include-transitive to find conflicts.
3. Wrong file edited for version -- The command updated .csproj but the solution uses Directory.Packages.props, or vice versa. Verify which management strategy is in place by checking the solution root for Directory.Packages.props before running updates.