Central package version management#9885
Conversation
joeloff
left a comment
joeloff
left a comment
There was a problem hiding this comment.
SignCheck and workload changes look fine to me, thank you.
| <TestPackage Include="runtime.any.System.Runtime" VersionOverride="4.3.0" /> | ||
| <TestPackage Include="runtime.aot.System.Runtime" VersionOverride="4.3.0" /> | ||
|
|
||
| <PackageReference Include="@(TestPackage)" /> |
There was a problem hiding this comment.
You might consider migrating to use PackageDownload for these; that's a bit cleaner representation of what you want to do with them.
There was a problem hiding this comment.
? Instead of adding them to "PackageReference"? That would be ideal, because I think that would avoid a lot of mess I had to do.
There was a problem hiding this comment.
Note that this is a legacy project and I expect it to go away when migrated all repos off from .pkgprojs.
|
Since package versions are now stored in both Directory.Packages.props and eng/Versions.props, it seems like it would be hard to keep track of where to update what. Is there any advice on how to manage this cleanly? Such as, only track versions for package subscriptions in Versions.props? |
|
@JoeRobich, the package versions were already haphazardly stored... Most were in Versions.props, but some were arbitrarily included verbatim in csprojs (those are the versions that are encoded in Version.props). I'm not sure what the best route forward is... personally I find Versions.props to be a headache, but it's all the maesto can update, so it needs to be present at least for any package that takes part in dependency flow. In addition, some of the variables defiend in that file are used in various places in arcade... so remove them is going to be a difficult, error prone process (because msbuild tends to just... keep on chugging if you try to use an undefined variable). We could go the other direction, and put ALL the version in Versions.props, and then just have to indirect everything. I think a better long term solution is that Maestro understands Directory.Packages.props, and then we wouldn't need Versions.props at all, but we aren't at that place right now. |
|
I started a source-build tarball build locally to see if this affects the prebuilt situation. |
ChadNedzlek
dismissed stale reviews from rainersigwald, michellemcdaniel, joeloff, and alexperovich
via
c2928cb
src/SignCheck/Microsoft.SignCheck/Microsoft.DotNet.SignCheckLibrary.csproj
Show resolved
Hide resolved
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Apparently NuGet/Home#10311 will cause a pretty big mess if we take this right now, so I'm closing this PR. Darn. |
8 participants
Use central package versions to help pulling versions forward be easier.
Had to suppress a few new warnings and, in a few places, override the versions backward
because of breaking changes.
If this doesn't break the world, I'll be shocked.