Enable central package management implicitly when Directory.Packages.props exists

[jeffkl]

Bug

Fixes: NuGet/Home#11834

Regression? Last working version:

Description

This change makes it so the presence of a Directory.Packages.props means that central package management is implicitly on. I've had countless people ask over the last year why you have to have the file and explicitly set ManagePackageVersionsCentrally to true. The logic now assumes if Directory.Packages.props exists then ManagePackageVersionsCentrally should be true unless the user has already set that property to a value, including if its set in Directory.Packages.props. This will make it easier for customers to onboard.

This is a redo of #5540 which was closed during the holiday break but then I forced pushed a rebase which GitHub then prevents me from re-opening.

PR Checklist

• PR has a meaningful title

• PR has a linked issue.

• Described changes

• Tests

  • Automated tests added
  • OR
  • Test exception
  • OR
  • N/A

• Documentation

  • Documentation PR or issue filled
  • OR
  • N/A

[ViktorHofer]

Note that this broke dotnet/runtime#98476 when upgrading to .NET 9 Preview 1. This is because previously an empty Directory.Packages.props file was created to avoid importing a root one. We understand the right fix but it might be worthwhile to write a breaking change notice for this.

[jeffkl]

Note that this broke dotnet/runtime#98476 when upgrading to .NET 9 Preview 1. This is because previously an empty Directory.Packages.props file was created to avoid importing a root one. We understand the right fix but it might be worthwhile to write a breaking change notice for this.

Sorry about that. Unfortunately its to be expected any repository that's running tests where those tests are going to import the repo's build logic and the repo is using CPM but the tests are not. We really wanted to reduce the friction with onboarding but knew that a couple repos would need to update to explicitly disable CPM for their tests.