Home: CPVM equivalent of GlobalPackageReference?

Created on 20 Oct 2020  路  6Comments  路  Source: NuGet/Home

We're looking at migrating from https://github.com/microsoft/MSBuildSdks/tree/master/src/CentralPackageVersions to the built-in central package versioning feature, and (unless I missed it) I didn't see an equivalent of GlobalPackageReference.

I'm guessing that for all of our (many) build/analyzer packages, we can do the equivalent and manually add both PackageVersion and PackageReference (with IncludeAssets and PrivateAssets set as GlobalPackageReference does)? Is there any reason we shouldn't add the PackageReferences directly in Directory.Packages.props?

RestoreCPVM PackageReference Investigate Feature

All 6 comments

/cc @cristinamanum

Also adding @zivkan

@zarenner I believe you're correct. I'm not aware of any equivalent feature. I agree that a PackageReference in Directory.Packages.props is a good alternative. You'll need to add the PrivateAssets and IncludeAssets yourself in this case.

@rconard I don't know if you've seen this feature before, but it sounds interesting. There are a few public repos on github using it.

@zarenner, thank you for raising this!

This is not currently in the design doc, but this feature is still very young.

If you could please give us some additional context on how you're using GlobalPackageReference and what you did prior to MSBuild SDK, that would be helpful.

We would also like to hear from more users of MSBuild SDK about how you're using GlobalPackageReference.

@rconard we have ~15 GlobalPackageReferences, the vast majority of which are code analyzers which we want to run against all projects.

We also have a few packages which use props/targets imports from the build folder to do things like enforce code structure, or provide some tools via nuget package and define their location as a property.

We introduced Microsoft.Build.CentralPackageVersions right around when we switched from packages.config to PackageReference style restore, so what we did prior isn't especially relevant. That said, at one point we did have a special project we called Externals which all projects depended on and triggered a package restore if necessary, before wiring in props/targets for the "global" tools/build-time packages.

Historically we've had a _way too much_ custom nuget-related code IMO (we implemented our own global packages cache at one point to work around nuget limitations), which is why I'd love to get as close as possible to "nuget as it's meant to be used".

Thanks for the information @zakramer. I just want to make sure that you are aware Central Package Version Management is still in preview, but we are happy to help with other questions you may have along the way.

Was this page helpful?
0 / 5 - 0 ratings