For over 12 years, NuGet package management has been part of the .NET ecosystem with direct integrations to various IDEs, CLIs and build systems. But a feature took 12 years before it appeared and certainly needs some more maintenance until it is mature!

The issue

Regardless of the code version management strategy, mono-repository vs. poly-repository, there has always been a need to synchronize the individual projects in the versions of NuGet packages used. Reasons for this are compatibility and security, but also new functionalities or bug fixes.

Earlier approaches

Over the years, the requirements in this area have evolved more and more, so that the previous solution approaches increasingly reached their limits. Not only the uniform use of the same package version, but also the general use of a package in all related projects of a solution was taken up and developed further in this context. However, the main shortcoming could never be solved; until now, manual intervention by a developer was always necessary to update the version of the packages used. The existing integrations of IDEs and CLIs produced more errors than they could fix.

Central Package Management (CPM)

Now the request has been fulfilled and in April 2022 the Central Package Management (“CPM”) was introduced and released along with NuGet version 6.2 and some complementary features.

To enable central package management, the MSBuild property ManagePackageVersionsCentrally is set to true in the Directory.Packages.props file.

For version listing and management, PackageVersion elements are required, each containing the package name and the version to be used. The next step is to remove the Version attribute from all PackageReference elements in the project files. This migrates the solution and it will use the central package management from now on.

Additional feature: Transitive pinning

Setting the MSBuild property CentralPackageTransitivePinningEnabled to true tells NuGet to update all transitive dependencies from their explicitly defined dependencies. This property can be set in both Directory.Build.props and the aforementioned Directory.Packages.props.

Additional feature: Global Package References

Another feature is GlobalPackageReference, which can be used to reference a package in any project of the solution / repository, such as code analyzer. This kind of package referencing should also be done in Directory.Packages.props.

Summary

All in all, a great enhancement to the NuGet system. However, there are currently some issues with the Visual Studio or .NET CLI integration.

Both integrations are able to evaluate the package references and recover the packages. However, when updating with Visual Studio, the XML structure of the project is updated incorrectly, so manual rework is required.

When the .NET CLI wants to add a reference to a project, CPM is ignored and build errors occur again.

However, this should not deter you, because existing integrations such as GitHubs Dependabot provide excellent results.