[DCR]: Central Package Management - Respect .props file as a way to opt-in to the feature.

[JonDouglas]

NuGet Product(s) Affected

Other/NA

Current Behavior

To opt-in to central package management, one must explicitly enable a MSBuild property today. This brings quite a bit of confusion to users given the original spec mentions that if a file exists, all projects will be opted-in to the feature.

https://github.com/NuGet/Home/wiki/Centrally-managing-NuGet-package-versions#opt-in-central-package-version-management

Desired Behavior

If a .props file exists or is imported appropriately, projects should be automatically opted-in to central package management unless there is an explicit MSBuild property disabling the use of the feature.

Additional Context

This is currently a papercut that brings confusion to everyday users. We have documented this for now, but would like to make this more intuitive in the future.

Breaking Change

This would be considered a breaking change in the scenario where a user has a Directory.Packages.props for some reason and is not setting the ManagePackageVersionsCentrally property. CPM would now be on and they would need to set ManagePackageVersionsCentrally to false explicitly if they don't want to use CPM.

<PropertyGroup>
  <ManagePackageVersionsCentrally>false</ManagePackageVersionsCentrally>
</PropertyGroup>

[knocte]

To opt-in to central package management, one must explicitly enable a MSBuild property today.

Is this bug outdated? I ask because you're saying that devs that want CentralPackageManagement need to opt-in via MSBuild property, but the URL you quote (https://github.com/NuGet/Home/wiki/Centrally-managing-NuGet-package-versions#opt-in-central-package-version-management ) says that it's enough to have the .props file.

[aortiz-msft]

We have decided to revert this breaking change based on customer feedback.

[CZEMacLeod]

Spent a long time fixing this in a solution of 100+ projects, some of which used CPM (opt-in) and some didn't. The D.P.p file existed (for those that opted-in) but then broke everything else. Glad to see this reverted. I'm not a big fan of the 'magic file' mechanism - at least not unless there is a 'soft-on' mechanism. If it was possible to have it use PackageVersion if they exist, but allow the direct version refs in PackageReference, in a sort of mixed mode without warnings/errors - it would allow this to be much smoother. Then you could opt-in, opt-out, or have the default as mixed.

CPM doesn't work very well for multi-targetting when you need different versions based on target framework - so it is not a total panacea and shouldn't be the default.