lr-nuget-update

A command-line tool to keep your NuGet packages up to date when using Central Package Management (Directory.Packages.props). It scans your solution, checks for newer versions, and updates your centralized configuration automatically.

Usage

Run it directly with dnx:

dnx -y lr.Dotnet.NugetUpdateTool [directory] [--allow-major] [--filter <globs>] [--config-file <path>] [--group-by-repository] [--allow-downgrade] [--skip-dependency-check] [--dedup]

Examples

Update packages in the current directory:

dnx -y lr.Dotnet.NugetUpdateTool

Allow major version updates:

dnx -y lr.Dotnet.NugetUpdateTool --allow-major

Update packages in a specific project or solution folder:

dnx -y lr.Dotnet.NugetUpdateTool ./src/MyProject

Only touch one package family, and move it as a unit:

dnx -y lr.Dotnet.NugetUpdateTool --filter 'HDH.Shared.*' --group-by-repository --allow-major

Use exactly one NuGet config file instead of the discovered hierarchy:

dnx -y lr.Dotnet.NugetUpdateTool --config-file "$HOME/.nuget/NuGet/NuGet.Config"

Remove duplicate PackageVersion entries (no version update):

dnx -y lr.Dotnet.NugetUpdateTool --dedup

Options

How it works

The tool follows a smart process to ensure your solution is updated safely and correctly:

1. Solution Discovery It finds your .sln or .slnx file. If not found in the current directory, it searches up the folder tree (up to 10 levels) until it locates one.
2. Project & Package Scanning It identifies all .csproj and Directory.Build.props files within the solution and extracts all used NuGet packages.
3. Version Checking It queries your configured NuGet sources (including private ones from your nuget.config) for the latest available versions.
4. Safe Updates By default, it only updates to the latest version within the same major version. This prevents breaking changes while ensuring you get the latest bug fixes and minor improvements. To allow major version updates, use the --allow-major flag. Prerelease versions are only considered when the current pin is itself a prerelease. With --group-by-repository, packages published from one repository (same nuspec repository url) are treated as one release train and always move to one common version, which avoids partial bumps that fail restore (NU1109).
5. Dependency Check The selected versions are checked against the nuspec dependencies of every pinned package (for the target frameworks of the solution's projects). A pin that a bumped package needs newer is raised along (e.g. Microsoft.Data.SqlClient.SNI.runtime with Microsoft.Data.SqlClient, which would otherwise fail restore with NU1109), even across its major. A bump that needs a pin which cannot move — held in an imported file, excluded by --filter, or already held back — is held back to the newest version whose requirements are met, or to its current pin (NU1605). A pin moved above the range a dependent accepts is lowered again (NU1608). Repository groups move as one unit. A conflict neither side can resolve, typically one the pins already had, is only reported.
6. Centralized Management
   • It writes updates directly to Directory.Packages.props.
   • If the file doesn't exist, it creates one and enables Central Package Management for you.
   • It ensures Directory.Packages.props is added to your "Solution Items" folder so it's easily accessible in your IDE.

Held pins and version ranges

• Pins in imported files are held. PackageVersion entries in a file that Directory.Packages.props or a Directory.Build.props imports (for example a Directory.Packages.locked.props holding a set of packages that must move together) are never updated and never added a second time to Directory.Packages.props, even when a project references the package. Imports are followed when their path uses no property other than $(MSBuildThisFileDirectory); conditions are not evaluated. A package pinned both in Directory.Packages.props and in an imported file triggers a loud warning and is left untouched — remove the Directory.Packages.props entry.
• Version ranges stay ranges. Only the lower bound moves, so an upper bound keeps holding on every later run, --allow-major included: [2.9.0,3.0.0) becomes [2.12.2,3.0.0), never 3.x. An exact range such as [2.12.2] holds the version completely. Use a range for a pin whose ceiling matters (for example a transitive pin that a dependency constrains) instead of a comment.

Good to know

• CPM Support: This tool is specifically designed for projects using Central Package Management.
• Transitive Pinning: When creating a new Directory.Packages.props, it enables CentralPackageTransitivePinningEnabled by default.
• Safety: As with any tool that modifies project files, it's recommended to run this on a clean git state so you can easily undo the changes if needed.
• Requirements: Requires .NET 10.0 or later.

Installation

If you prefer to have it installed globally on your machine:

dotnet tool install -g lr.Dotnet.NugetUpdateTool

Usage after installation:

lr-nuget-update [directory] [--allow-major] [--filter <globs>] [--config-file <path>] [--group-by-repository] [--allow-downgrade] [--skip-dependency-check] [--dedup]