NuGet package management best practices including versioning strategies, central package management, and dependency resolution. Use when setting up Central Package Management (CPM), managing package versions across multiple projects, or resolving dependency conflicts in .NET solutions.

NuGet Package Management When to Use This Skill Use this skill when: Adding, removing, or updating NuGet packages Setting up Central Package Management (CPM) for a solution Managing package versions across multiple projects Troubleshooting package conflicts or restore issues Golden Rule: Never Edit XML Directly Always use dotnet CLI commands to manage packages. Never manually edit .csproj or Directory.Packages.props files. Why: CLI validates package exists and resolves correct version Handles transitive dependencies correctly Updates lock files if present Avoids typos and malformed XML Works correctly with CPM Central Package Management (CPM) CPM centralizes all package versions in one file, eliminating version conflicts across projects. Enable CPM Create Directory.Packages.props in solution root: Project Files with CPM Projects reference packages without versions : Adding Packages with CPM Shared Version Variables Group related packages with shared version variables: Benefits: Update all Akka packages by changing one variable Clear organization with labeled ItemGroups Prevents version mismatches in related packages When NOT to Use CPM Central Package Management isn't always the right choice: Legacy Projects Migrating an existing large solution to CPM can introduce issues: Existing version conflicts become visible all at once Some packages may have intentional version differences Migration requires touching many files simultaneously Recommendation : For legacy projects, migrate incrementally or stick with per project versioning if it's working. Version Ranges CPM requires exact versions it doesn't support version ranges: If you need version ranges (rare, but some library scenarios require it), CPM won't work. Older .NET Versions CPM requires: .NET SDK 6.0.300+ or later NuGet 6.2+ or later Visual Studio 2022 17.2+ or later If you're targeting older SDK versions or have team members on older tooling, CPM may cause build failures. Multi Repo Solutions If your solution spans multiple repositories that are built independently, CPM's single Directory.Packages.props won't help each repo needs its own. CLI Command Reference Adding Packages Removing Packages Listing Packages Updating Packages Restore and Clean Package Sources List Sources Add Private Feed NuGet.config For solution specific sources, create NuGet.config : Common Patterns Development Only Packages Conditional Packages Version Override (Escape Hatch) When you must override CPM for one project (rare): Warning : This is detected by Slopwatch (see dotnet/slopwatch skill) as potential slop. Troubleshooting Version Conflicts Restore Failures Lock Files For reproducible builds, use package lock files: Then commit packages.lock.json files. Anti Patterns Don't: Edit XML Directly Don't: Inline Versions with CPM Don't: Mix Version Management Don't: Forget Shared Variables Quick Reference Task Command Add package dotnet add package <name Add specific version dotnet add package <name version <ver Remove package dotnet remove package <name List packages dotnet list package Show outdated dotnet list package outdated Show vulnerable dotnet list package vulnerable Restore dotnet restore Clear cache dotnet nuget locals all clear Resources Central Package Management : https://learn.microsoft.com/en us/nuget/consume packages/central package management dotnet CLI Reference : https://learn.microsoft.com/en us/dotnet/core/tools/ NuGet.config Reference : https://learn.microsoft.com/en us/nuget/reference/nuget config file

package-management