Managing NuGet packages across multiple projects can be a complex and time-consuming task, especially for growing solutions in .NET, .NET MAUI, Azure, or Blazor applications. At Assemblysoft, we empower businesses to streamline dependency management using Central Package Management (CPM), a powerful feature of NuGet that simplifies version control and enhances consistency across projects.

The Challenges of Dependency Management

In multi-project solutions, dependency management becomes increasingly difficult as the number of projects scales. For example, a Blazor web application, .NET MAUI mobile app, and Azure-based API might all share libraries like Serilog, Polly, or Newtonsoft.Json. Without a centralized approach, issues such as mismatched versions can arise:

  • Project A uses Serilog 4.1.0
  • Project B uses Serilog 4.0.2
  • Project C uses Serilog 3.1.1

These inconsistencies can lead to hard-to-diagnose bugs and disrupt the development process. Assemblysoft’s expertise ensures your projects are free from such headaches by adopting a structured approach with CPM.

Simplify with Central Package Management

Central Package Management provides a unified control center for managing dependencies across .NET, .NET MAUI, Azure, and Blazor projects. Here are the prerequisites to get started:

  • NuGet 6.2 or newer
  • .NET SDK 6.0.300 or newer
  • Visual Studio 2022 (version 17.2 or newer)

CPM centralizes version control in a single Directory.Packages.props file, ensuring consistency across all projects.

Setting Up Central Package Management

Follow these steps to enable CPM in your solution:

Create the Directory.Packages.props File

Place this file in the root directory of your solution:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
    <PackageVersion Include="Serilog" Version="4.1.0" />
    <PackageVersion Include="Polly" Version="8.5.0" />
  </ItemGroup>
</Project>

Update Project Files

Replace individual version specifications with references that rely on the central file:

<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" />
  <PackageReference Include="Serilog" />
  <PackageReference Include="Polly" />
</ItemGroup>

Extend for Multi-Layered Solutions

For applications integrating .NET APIs, Azure services, Blazor frontends, and .NET MAUI clients, use CPM to manage shared dependencies across all layers.

Advanced Features of CPM

Custom Version Overrides

Need a specific version for a project? Use the VersionOverride property:

<PackageReference Include="Serilog" VersionOverride="3.1.1" />

Global References

Include dependencies required by all projects globally:

<ItemGroup>
  <GlobalPackageReference Include="SonarAnalyzer.CSharp" Version="10.3.0.106239" />
</ItemGroup>

Transitive Pinning

Manage transitive dependencies by enabling CentralPackageTransitivePinningEnabled:

<PropertyGroup>
  <CentralPackageTransitivePinningEnabled>true</CentralPackageTransitivePinningEnabled>
</PropertyGroup>

Why CPM Matters for .NET, Azure, Blazor, and .NET MAUI Projects

For a comprehensive platform like .NET, CPM ensures:

  • Consistency: Unified dependency management across Azure cloud services, Blazor web apps, .NET APIs, and .NET MAUI mobile apps.
  • Efficiency: Reduces duplicate efforts in managing versions.
  • Scalability: Supports growing teams and solutions without adding complexity.

Pitfalls to Watch For When Adopting CPM

Most teams adopt CPM without drama, but a few recurring snags are worth knowing about before you start:

  • packages.config projects need converting first. CPM only works with PackageReference, so older projects still using packages.config must be migrated before they can join the central file. This is a common early step in our legacy .NET migration engagements.
  • Avoid a half-migrated solution. Once ManagePackageVersionsCentrally is enabled, a stray Version attribute left on a PackageReference will fail the restore. Convert the whole solution in one change rather than project by project.
  • Treat VersionOverride as an exception, not a habit. Every override is a small return to the problem CPM solves. We keep a comment beside each one explaining why it exists, and review them whenever dependencies are updated.
  • Understand transitive pinning before enabling it. Pinning promotes transitive packages to direct, centrally controlled versions, which is powerful but can change what gets restored. Switch it on deliberately and re-test, not as a default.
  • The props file becomes high-traffic. A single line now affects every project, so it deserves the same code review care as source code, backed by a CI build that restores the full solution.

Handled with a little care up front, none of these should slow you down, and the payoff in consistency across a growing .NET solution arrives immediately.

Migrating Existing Projects to CPM

At Assemblysoft, we guide businesses in seamlessly transitioning to CPM:

  1. Create a Directory.Packages.props file at the solution root.
  2. Move package versions from individual project files to the props file.
  3. Remove Version attributes from <PackageReference> elements.
  4. Build and resolve conflicts.
  5. Test thoroughly before committing changes.

For automation, tools like CentralisedPackageConverter simplify this process:

# Install the tool globally
dotnet tool install CentralisedPackageConverter --global

# Convert your solution
central-pkg-converter /PATH_TO_YOUR_SOLUTION_FOLDER

Still current in 2026

Update, August 2026: Everything in this article still applies, and if anything the case has strengthened: Central Package Management has gone from a nice-to-have to the default recommendation for any .NET solution with more than a couple of projects. New solution templates and team conventions increasingly assume a Directory.Packages.props at the root, and the feature has continued to mature through recent NuGet and .NET SDK releases — including .NET 10, the current LTS — so there is no reason to hold off adopting it.

CPM also pairs well with the wider dependency hygiene now expected as standard: NuGet’s built-in package auditing flags known vulnerabilities at restore time, and a single central file makes those updates a one-line change instead of a hunt across every project. If you would like help migrating a larger solution, our custom software development team does this regularly as part of modernisation work.

Assemblysoft: Your Partner in .NET Project Excellence

At Assemblysoft, we specialise in building robust solutions for .NET, Azure, Blazor, and .NET MAUI projects. Whether you’re developing cloud-based applications, interactive web frontends, or cross-platform mobile apps, our team has the expertise to optimize your workflows with CPM and other best practices.

Let’s Get Started

Ready to take your .NET projects to the next level? Contact Assemblysoft today to learn how our solutions can transform your development process, saving you time and ensuring project success.

References

https://learn.microsoft.com/en-us/nuget/consume-packages/central-package-management

https://github.com/Webreaper/CentralisedPackageConverter