Choosing Between Centralized and Decentralized NuGet Package Management in .NET SDK 6.0+ Solutions

Create Directory.Packages.props next to the solution file:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
    <PackageVersion Include="Microsoft.Extensions.Logging.Abstractions" Version="8.0.0" />
    <PackageVersion Include="Serilog.AspNetCore" Version="8.0.0" />
  </ItemGroup>
</Project>

The ManagePackageVersionsCentrally property tells the SDK to read the PackageVersion items.

2. Update project files

In each project (MyApp.csproj, MyApp.Tests.csproj, etc.) remove any version attributes from the referenced packages:

<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" />
  <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" />
  <PackageReference Include="Serilog.AspNetCore" />
</ItemGroup>

3. Restore and inspect

Run the restore command from the solution directory:

dotnet restore

This generates obj/project.assets.json for each project. Open one of these files and locate a package entry; the version field should match the value from Directory.Packages.props unless the project explicitly overrides it.

4. Validate no version conflicts

Build the solution:

dotnet build

If the build succeeds without warnings about version conflicts, central management is active. Optionally, run:

dotnet list package --vulnerable

to confirm that all packages resolve to the intended versions.

5. Testing an override (optional)

To verify that a project‑level version still wins, add a version attribute in one project:

<PackageReference Include="Newtonsoft.Json" Version="12.0.3" />

After another restore, the obj/project.assets.json for that project will show 12.0.3 while the other projects retain 13.0.3 from the central file.

Limitations and practical checks

Centralized management does not apply to projects that still use packages.config. Those projects must be migrated via dotnet migrate packages.config or manually converted to PackageReference before the central file takes effect.

Because overrides are allowed, it is good practice to audit the solution periodically:

1. Search for any Version attributes inside PackageReference elements:

grep -r "Version=" **/*.csproj

2. Ensure that any found overrides are intentional and documented.

If you discover unintended overrides, remove the version attribute or adjust the central PackageVersion entry accordingly.

When to choose each option

Choose centralized management (Option A) when:

• The solution contains many projects that share a common set of libraries.
• You want to enforce a single version policy to avoid dependency hell.
• You are willing to invest the one‑time migration effort.

Choose decentralized management (Option B) when:

• Projects have divergent version requirements (e.g., one targets .NET Framework 4.8 while another targets .NET 8).
• You are experimenting with pre‑release packages and need isolation.
• The solution is small enough that manual version tracking does not become burdensome.

---

By following the steps above, you can decide whether centralized NuGet package management fits your solution’s constraints, implement it with a Directory.Packages.props file, and verify that the intended versions are applied across all projects.