Partial Central Package Management

[martinsuchan]

NuGet Product(s) Involved

NuGet.exe, Visual Studio Package Management UI, Visual Studio Package Manager Console, MSBuild.exe, dotnet.exe, NuGet SDK

The Elevator Pitch

I like the idea of NuGet Central Package Management, but if developer wants to use it, it's either all or nothing.
If we have solution with 200+ projects referencing together 150+ different NuGet packages, migrating to CPM would be a nightmare right now.

Feature request: We'd like to start using CPM with only some NuGet packages managed centrally at the beginning, like Newtonsoft.Json and Microsoft.NET.Test.Sdk, and continuously keep adding new nugets to the list of centrally managed packages.

When I tried in VS 2022 17.4, I received error:
error NU1008: Projects that use central package version management should not define the version on the PackageReference items but on the PackageVersion items

Additional Context and Details

No response

[jeffkl]

You can opt-out individual projects by setting the ManagePackageVersionsCentrally property to false. To do this on a per-PackageReference basis, you'd need to update all of your <PackageReference /> items to use VersionOverride instead of Version:

<ItemGroup>
  <PackageReference Include="PackageA" VersionOverride="1.0.0" />
  <PackageReference Include="PackageB" VersionOverride="2.0.0" />
  <PackageReference Include="PackageC" />
</ItemGroup>

In that example, PackageC would be getting its version from Directory.Packages.props but PackageA and PackageB would have the version still specified in the project. You could potentially use a search-and-replace to update your projects and then start moving individual package versions.

[martinsuchan]

I know about the possibility to disable CPM for selected projects, but that's not what we want.
Id' like to start centrally manage only selected simple packages, and keep the rest PackageReferences as they are right now:

<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" />
  <PackageReference Include="Microsoft.AspNetCore.SignalR.Client" Version="7.0.0" />
  <PackageReference Include="Microsoft.Extensions.Primitives" Version="7.0.0" />
</ItemGroup>

This is actually how I understood the blog post when I read it first, that it is possible to use this feature partially for some NuGet packages and keep adding new packages to the central list over time, while keeping some packages in projects the old way.
https://devblogs.microsoft.com/nuget/introducing-central-package-management/

Note right now we use properties with nuget versions in Directory.Build.props for the same purpose and I was hoping switching to CPM could improve the clarify of our current solution:

<PropertyGroup>
  <NewtonsoftJsonVersion>13.0.2</NewtonsoftJsonVersion>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" Version="$(NewtonsoftJsonVersion)" />
</ItemGroup>

[jeffkl]

The only way to get some package references to be centrally managed and others not, is to use VersionOverride. This should give you what you're after.

Properties that represent the version can still be used in Directory.Packages.props:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>

    <NewtonsoftJsonVersion>13.0.2</NewtonsoftJsonVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="$(NewtonsoftJsonVersion)" />
  </ItemGroup>
</Project>

[martinsuchan]

Partially related question, is there any option to convert PackageReferences from the standard format to CPM automatically? doing this manually for 200+ projects would take me days at least, not to mention possible version collisions that may arise in the process.

[jimmylewis]

I saw https://github.com/Webreaper/CentralisedPackageConverter recommended in a StackOverflow post (haven't used it myself). Not sure how it handles version conflicts. There may be other similar tools too.

[jeffkl]

We are looking into developing an onboarding tool for central package management, which is tracked here. There are also some 3rd party tools as @jimmylewis mentioned.

[ghost]

This issue has been automatically marked as stale because we have not received a response in 14 days. It will be closed if no further activity occurs within another 14 days of this comment.

[isaac-mcgarvey-tfs]

Here's my understanding of the current behavior:
Once you enable central package management, all PackageReferences must not have a Version. They can have VersionOverride, but any Version will cause an error.

As a first-time user of the feature trying to add central package management incrementally, what I would prefer is that a PackageReference is allowed to have a Version, as long as that Version doesn't conflict with the centrally-defined one. So if the PackageReference Version is the same as the central PackageVersion Version, you don't get an error. Or if there is no PackageVersion defined for that package, you don't get an error. You would only get an error if PackageVersion is defined and has a different Version than the PackageReference.

With the current behavior, I need to update every single PackageReference in all my projects in order to enable the feature, even if it's just basically doing a string replace of "Version" => "VersionOverride". Besides the fact that that's a hassle, I don't really want to set VersionOverride on all the packages that I'm not ready to declare a central version for yet. The reason I don't want to do that is I have no specific intention of having those versions be different. So I actually would like to get an error if, later on, I do declare a central version for those packages and some projects have a version that doesn't match. If I set it to VersionOverride now, that won't happen.

So I don't think saying just change Version to VersionOverride is a good solution. It seems like tweaking the behavior of the feature a little would make adoption easier.

[rjgotten]

The lack of support for floating package versions and automatically opting into latest patch versions with security updates, makes CPM currently a complete no-go.

The ability to only have a few packages centrally managed for convenience's sake -- like test SDK; test adapters; etc. -- or to only pin a few transitive dependencies -- because you're stuck in a situation such as this one -- is what would give it value.

If it's an all-or-nothing; then in its current state, the choice is easy: nothing.
And whatever manner of shared packages should be centrally managed can be done in manually centralized .props files, hooked up to individual project files via explicit <Import>.