[Epic]: Central Package Management improvements for 17.4

[jeffkl]

Issues

• [Feature]: Add ability to designate a package reference as used by every project in the repo #10159
• [Bug]: Metadata like PrivateAssets does not flow from parent to transitively pinned dependency in CPM #10311
• [DCR]: Central package management package source mapping should only look at configured feeds #11951
• [Bug]: "An item with the same key has already been added" when migrating to CPM with ProjectDependencies in solution file #12021
• [DCR]: Remove preview message when using central package management #11950
• [DCR]: Issues with new NU1507 warning #11822
• ------------------------------------------ Cut line --------------------------------------------
• [Performance]: Find a solution with better performance to reject the central transitive dependencies that have rejected parents.  #9740
• [Bug]: When using the CentralPackageTransitivePinningEnabled feature please avoid redundant references #11818
• [Bug]: Package downgrade and error messages #10126
• [DCR]: Allow floating versions with Central Package Management (CPM) #10432
• [Performance]: Improve Commit Async for CPVM enabled projects #10256

Features

• No one location to specify metadata like NoWarn
  Since Microsoft.Build.CentralPackageVersions uses the Update guesture, it lets users specify a version for a package as well as other metadata like NoWarn. However, in NuGet's CPM we only have a <PackageVersion /> item and it wouldn't make sense to specify NoWarn on a package version. Users will need to add a <PackageReference Update="" NoWarn="1234" /> to their Directory.Packages.props.

Pull Requests

• Flow PrivateAssets to transitively pinned centrally managed dependencies NuGet.Client#4669
• [Proposal]: Global Package Reference for Central Package Management #11794
• Add concept of repo-wide package reference when using central package management NuGet.Client#4680
• Ignore local sources when enforcing package source mapping with central package management NuGet.Client#4764
• Properly handle duplicate central package version items in the restore graph when using custom build ordering in a solution file NuGet.Client#4776
• Document NU1507 docs.microsoft.com-nuget#2873
• Remove preview message related to using central package management NuGet.Client#4782

Documentation

• Document GlobalPackageReference #12073
• Document NU1507 #12072

[jeffkl]

Related to

• [Epic]: Tooling support for central package management #9015

[AArnott]

Please seriously consider #9464 as part of this. It's a very important scenario for us.

[jeffkl]

Please seriously consider #9464 as part of this. It's a very important scenario for us.

@AArnott I thought when we discussed #9464 that we came to the conclusion that some tooling was needed there? NuGet restores each project in a silo due to the nature of how .NET builds work. NuGet doesn't know that another project is transitively referencing a different version of a dependency unless those two projects depend on each other. To truly achieve what #9464 asks for, we'd need tooling like Dependabot to analyze a whole repository to unify the dependency tree. Central package management allows us to define package versions in one location but won't be directly addressing updates across entire repositories transitively when projects don't reference each other. That said, I still think it would be awesome for a tool like that to exist.

[AArnott]

Oh yes, I remember now. Sad. Maybe we should close #9464 with the explanation then. I can't because someone on the NuGet team created that issue on my behalf.

[jeffkl]

I'll update the issue and leave it open for now. I still like the idea of it all, I just don't think central package management can solve it at this time.

[jeffkl]

Closing now that all work is complete for this epic. This item tracks additional work related to tooling: #9015

[robmen]

This Epic is closed, but issue #11822 is still open. Is the Cut line in the wrong place?

[jeffkl]

This Epic is closed, but issue #11822 is still open. Is the Cut line in the wrong place?

I'm fairly confident that the next release will address #11822 but I'm waiting for the person who opened the issue to get a preview version and see if they agree. I've left it open until then but will probably close it soon.

[DevBaburaj]

@jeffkl, is "No one location to specify metadata like NoWarn" part of this release? Asking as I don't see it "ticked" above nor is it mentioned in the 6.4 release announcement.

[jeffkl]

@jeffkl, is "No one location to specify metadata like NoWarn" part of this release? Asking as I don't see it "ticked" above nor is it mentioned in the 6.4 release announcement.

@DevBaburaj unfortunately I couldn't come up with a good design for PackageReference NoWarn in one place. Directory.Packages.props is imported at the top of a project so it can't do <PackageReference Update="" NoWarn="NU1000" /> and there's nothing else in central package management that made sense to extend at the moment.

Flowing NoWarn metadata from a PackageVersion seemed clunky since it really should just specify a version. We could potentially add yet another item like <PackageNoWarn Include="SomePackage" NoWarn="NU1000" /> but that's not great in my opinion.

The best solution if you want a particular package reference to always have a NoWarn for every project in your repository is to add this to your Directory.Build.targets:

<Project>
  <ItemGroup>
    <PackageReference Update="SomePackage" NoWarn="%(NoWarn);NU1000" />
  </ItemGroup>
</Project>

Otherwise you'll just need to specify the NoWarn metadata on the <PackageReference /> in each project. Depending on the size of your tree, this might not be too bad.

[zarenner]

Looks like .NET SDK 6.0.403 was released. I was hoping it'd include these improvements but appears not.
https://dotnet.microsoft.com/en-us/download/dotnet/6.0 originally said Included in Visual Studio ... 17.4.0 but now has been reverted back to say 17.3.7 (dotnet/core#7955) so I'm hoping this'll be in the next SDK release?

[jeffkl]

@zarenner Visual Studio 17.4 released with .NET SDK 7.0.100 and NuGet along with other components of the .NET developer ecosystem stopped inserting into .NET SDK 6.x. Are you able to use .NET SDK 7?

[zarenner]

@jeffkl thanks, wasn't aware. We were considering skipping .NET 7 (incl. sdk) at least for now as its a STS release, but this might change the equation since Microsoft.Build.CentralPackageVersions doesn't support transitive pinning and we really want it 😄. Have to reevaluate. I take it there's no easy way to get transitive pinning on 6?

[jeffkl]

I take it there's no easy way to get transitive pinning on 6?

Transitive pinning shipped in Visual Studio 2022 17.2 (NuGet/NuGet.Client#4025) and .NET SDK 6.0.3xx. But the features you'll miss in .NET SDK 6 are:

• GlobalPackageReference
• Metadata like PrivateAssets do not flow to transitively pinned references
• Preview message removal

.NET 7.0 is definitely worth checking out though...