You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently store the version of dependent NuGet packages centrally in Directory.Build.props using placeholder variables. This works, but when updating a package reference, the placeholder gets replaced with a hardcoded version. This requires a manual correction step.
A better solution is to instead use Directory.Packages.props, which works by leaving out the version from the package references in project files.
The text was updated successfully, but these errors were encountered:
Gave it another try, but we still can't use it because floating versions are blocked.
What could have been a pretty simple project (store versions globally) has become quite a nightmare. It handles transitive dependencies very differently, which makes floating versions hard to tackle and multiple package sources are problematic. To workaround this limitation, some people use version ranges instead, which come with their own issues. And the officially documented workarounds for them just don't work in combination with central package management. Users report all kinds of weird warnings/errors that shouldn't pop up. It seems that CPM is targeted at large enterprises that don't trust their developers and want to lock down everything.
We currently store the version of dependent NuGet packages centrally in
Directory.Build.props
using placeholder variables. This works, but when updating a package reference, the placeholder gets replaced with a hardcoded version. This requires a manual correction step.A better solution is to instead use Directory.Packages.props, which works by leaving out the version from the package references in project files.
The text was updated successfully, but these errors were encountered: