-
-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Centrally managed NuGet package versions #865
Comments
Update: this is available in .NET 7 Preview 4: https://docs.microsoft.com/nl-nl/nuget/consume-packages/Central-Package-Management. |
Well, this is still in preview. And not at all working very well. |
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. List of active issues at https://github.com/NuGet/Home/labels/Area%3ARestoreCPM. |
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: