Switch to central package management #3093
Conversation
There was a problem hiding this comment.
@tomap In principle I am okay with the idea of having centralized package management which is a good thing. That said, we have the following organization/groups of projects:
- Projects/libs which we publish to NuGet
- Projects for testing
- Projects for samples.
- Project pertaining to build system.
I would certainly want to keep explicit Directory.Packages.props for each so that it is lot more clearer to understand and manage things better. This way, we are not having the whole kitchen sink under one top level Directory.Packages.props.
This means that we may need to have a Directory.Packages.props at the top level with the packages needed for the core libraries, move all the unit tests under a parent folder named Tests & have a Directory.Packages.props specifically for tests and also a Directory.Packages.props for samples.
With regards to the build system, we don't want to mix it up at all so it should not be driven via the centralized Directory.Packages.props.
Towards the above, I will start making these changes to the project/code organization since folder structure changes will require changes to CI build etc.
@jeremydmiller Please chime in with your thoughts.
|
I understand. The conversion tool is certainly able to do that. And the nuget doc also explains how to handle that |
Rendons à César...
All the merit goes to the creator of https://github.com/Webreaper/CentralisedPackageConverter
Two things to note:
1/ there were multiple nugets with different versions. The migration bumped them to the max version that was referenced
2) Except for xUnit, for which I used version
instead of
which has a new analyzer which was not happy with the fixture injection in tests.
https://xunit.net/xunit.analyzers/rules/xUnit1041
As I was not sure which fix to apply, I chose the safe path: rollback to working version