Dependency management is a core feature of NuGet. Managing dependencies for a single project can be easy. Managing dependencies for multi-project solutions can prove to be difficult as they start to scale in size and complexity. In situations where you manage common dependencies for many different projects, you can leverage NuGet’s central package management features to do all of this from the ease of a single location.<\/p>\n
Historically, NuGet package dependencies have been managed in two main locations:<\/p>\n
packages.config<\/code> – An XML file used in older project types to maintain the list of packages referenced by the project.<\/li>\n<PackageReference \/><\/code> – An XML element used in new project types that manages NuGet dependencies directly within project files.<\/li>\n<\/ul>\nStarting with NuGet 6.2<\/a>, you can centrally manage your dependencies in your projects with the addition of a Directory.Packages.props<\/code> file.<\/p>\nThe feature is available across all NuGet integrated tooling.<\/p>\n
\n- Visual Studio 2022 17.2 and later<\/a><\/li>\n
- .NET SDK 6.0.300 and later<\/a><\/li>\n
- .NET SDK 7.0.0-preview.4 and later<\/a><\/li>\n
- nuget.exe 6.2.0 and later<\/a><\/li>\n<\/ul>\n
Older tooling will ignore Central Package Management configurations and features. To use this feature to the fullest extent, ensure all your build environments use the latest compatible tooling versions.<\/p>\n
Central Package Management will apply to all <PackageReference><\/code> projects \u2013 including legacy .csproj<\/a> \u2013 as long as compatible tooling is used.<\/p>\nEnabling Central Package Management<\/h2>\n
To get started with central package management, you can create a Directory.Packages.props<\/code> file at the root of your solution and set the MSBuild property ManagePackageVersionsCentrally<\/code> to true<\/code>.<\/p>\nInside, you can define each of the respective package versions required of your solution using <PackageVersion \/><\/code> elements that define the package ID and version.<\/p>\n<Project>\n <PropertyGroup>\n <ManagePackageVersionsCentrally>true<\/ManagePackageVersionsCentrally>\n <\/PropertyGroup>\n <ItemGroup>\n <PackageVersion Include=\"Newtonsoft.Json\" Version=\"13.0.1\" \/>\n <\/ItemGroup>\n<\/Project>\n<\/code><\/pre>\nWithin a project of the solution, you can then use the respective <PackageReference \/><\/code> syntax you know and love, but without a Version<\/code> attribute to infer the centrally managed version instead.<\/p>\n<Project Sdk=\"Microsoft.NET.Sdk\">\n\n <PropertyGroup>\n <TargetFramework>net6.0<\/TargetFramework>\n <\/PropertyGroup>\n\n <ItemGroup>\n <PackageReference Include=\"Newtonsoft.Json\" \/>\n <\/ItemGroup>\n<\/Project>\n<\/code><\/pre>\nNow you’re using central package management and managing your versions in a central location!<\/p>\n
Central Package Management rules<\/h2>\n
The Directory.Packages.props<\/code> file has a number of rules with regards to where it’s located in a repository’s directory and its context. For the sake of simplicity, only one Directory.Packages.props<\/code> file is evaluated for a given project.<\/p>\nWhat this means is that if you had multiple Directory.Packages.props<\/code> files in your repository, the file that is closest to your project’s directory will be evaluated for it. This allows you extra control at various levels of your repository.<\/p>\nHere’s an example, consider the following repository structure:<\/p>\n
Repository\n |-- Directory.Packages.props\n |-- Solution1\n |-- Directory.Packages.props\n |-- Project1\n |-- Solution2\n |-- Project2\n<\/code><\/pre>\n\n- Project1 will evaluate the
Directory.Packages.props<\/code> file in the Repository\\Solution1\\<\/code> directory.<\/li>\n- Project2 will evaluate the
Directory.Packages.props<\/code> file in the Repository\\<\/code> directory.<\/li>\n<\/ul>\nGet started<\/h2>\n
To fully onboard your repository, consider taking these steps:<\/p>\n
\n- Create a new file at the root of your repository named
Directory.Packages.props<\/code> that declares your centrally defined package versions in.<\/li>\n- Declare
<PackageVersion \/><\/code> items in your Directory.Packages.props<\/code>.<\/li>\n- Declare
<PackageReference \/><\/code> items without Version<\/code> attributes in your project files.<\/li>\n<\/ol>\n<\/p>\n
Transitive pinning<\/h2>\n
You can automatically override a transitive package version even without an explicit top-level <PackageReference \/><\/code> by opting into a feature known as transitive pinning. This promotes a transitive dependency to a top-level dependency implicitly on your behalf when necessary.<\/p>\nYou can enable this feature by setting the MSBuild property CentralPackageTransitivePinningEnabled<\/code> to true<\/code> in a project or in a Directory.Packages.props<\/code> or Directory.Build.props<\/code> import file:<\/p>\n <PropertyGroup>\n <CentralPackageTransitivePinningEnabled>true<\/CentralPackageTransitivePinningEnabled>\n <\/PropertyGroup>\n<\/code><\/pre>\nOverriding package versions<\/h2>\n
You can override an individual package version by using the VersionOverride<\/code> property on a <PackageReference \/><\/code> item. This overrides any <PackageVersion \/><\/code> defined centrally.<\/p>\n<Project>\n <ItemGroup>\n <PackageVersion Include=\"PackageA\" Version=\"1.0.0\" \/>\n <PackageVersion Include=\"PackageB\" Version=\"2.0.0\" \/>\n <\/ItemGroup>\n<\/Project>\n<\/code><\/pre>\n<Project Sdk=\"Microsoft.NET.Sdk\">\n <PropertyGroup>\n <TargetFramework>net6.0<\/TargetFramework>\n <\/PropertyGroup>\n <ItemGroup>\n <PackageReference Include=\"PackageA\" VersionOverride=\"3.0.0\" \/>\n <\/ItemGroup>\n<\/Project>\n<\/code><\/pre>\nYou can disable this feature by setting the MSBuild property CentralPackageVersionOverrideEnabled<\/code> to false<\/code> in a project or in a Directory.Packages.props<\/code> or Directory.Build.props<\/code> import file:<\/p>\n <PropertyGroup>\n <CentralPackageVersionOverrideEnabled>false<\/CentralPackageVersionOverrideEnabled>\n <\/PropertyGroup>\n<\/code><\/pre>\nWhen this feature is disabled, specifying a VersionOverride<\/code> on any <PackageReference \/><\/code> item will result in an error at restore time indicating that the feature is disabled.<\/p>\nDisabling Central Package Management<\/h2>\n
If you’d like to disable central package management for any reason, you can disable this feature by setting the MSBuild property ManagePackageVersionsCentrally<\/code> to false<\/code>:<\/p>\n\n<PropertyGroup>\n <ManagePackageVersionsCentrally>false<\/ManagePackageVersionsCentrally>\n<\/PropertyGroup>\n<\/code><\/pre>\nWarning when using multiple package sources<\/h2>\n
When using central package management, you will see a NU1507<\/code> warning if you have more than one package source defined in your configuration. To resolve this warning, map your package sources with package source mapping<\/a> or specify a single package source.<\/p>\nThere are 3 package sources defined in your configuration. When using central package management, please map your package sources with package source mapping (https:\/\/aka.ms\/nuget-package-source-mapping) or specify a single package source.\n<\/code><\/pre>\nClosing<\/h2>\n
We hope that these features will help improve your productivity of managing your dependencies as they scale with your projects, promote healthy security best practices, and empower your team to achieve more with the ease of a single location. There is currently no support in Visual Studio or the .NET CLI for Central Package Management.<\/p>\n
Feedback<\/h2>\n
This feature is considered in preview and is under active development. Your feedback is important to us. If there are any problems with this feature, check our GitHub Issues<\/a>. For new issues within this experience, please report a GitHub Issue<\/a>. To help us with documentation, please feel free to contribute and ask questions<\/a> on how we can explain the feature further.<\/p>\n","protected":false},"excerpt":{"rendered":"Central Package Management Dependency management is a core feature of NuGet. Managing dependencies for a single project can be easy. Managing dependencies for multi-project solutions can prove to be difficult as they start to scale in size and complexity. In situations where you manage common dependencies for many different projects, you can leverage NuGet’s central […]<\/p>\n","protected":false},"author":88861,"featured_media":2369,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7933,7874],"tags":[7970,7971,7972,7973],"class_list":["post-2361","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-feature-announcement","category-nuget","tag-central-package-management","tag-central-package-version-management","tag-cpm","tag-cpvm"],"acf":[],"blog_post_summary":"
Central Package Management Dependency management is a core feature of NuGet. Managing dependencies for a single project can be easy. Managing dependencies for multi-project solutions can prove to be difficult as they start to scale in size and complexity. In situations where you manage common dependencies for many different projects, you can leverage NuGet’s central […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/2361","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/88861"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=2361"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/2361\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/2369"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=2361"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=2361"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=2361"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}