Skip to content
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

Provide a way to use CPM in an incremental mode #12768

Open
JonDouglas opened this issue Jul 20, 2023 · 8 comments
Open

Provide a way to use CPM in an incremental mode #12768

JonDouglas opened this issue Jul 20, 2023 · 8 comments
Labels
Area:RestoreCPM Central package management Functionality:Restore Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. Type:Feature

Comments

@JonDouglas
Copy link
Contributor

NuGet Product(s) Involved

Visual Studio Package Management UI, MSBuild.exe, dotnet.exe, NuGet SDK

The Elevator Pitch

For complex repositories that would like to adopt CPM, today it is all-or-nothing. The elevator pitch would be to have some type of "incremental" mode in which CPM can be respected by those packages that onboard a <PackageVersion> and lack Version in their <PackageReference>.

Perhaps a new mode such as <ManagePackageVersionsCentrallyMode> could have an incremental parameter or similar?

Additional Context and Details

No response

@turbodrubin
Copy link

See also #12316 for a previous request for this functionality from the community.

@zivkan
Copy link
Member

zivkan commented Jul 27, 2023

For complex repositories that would like to adopt CPM, today it is all-or-nothing

This isn't technically/pedentically true. A single project is all-or-nothing, but anyone is free to (ab)use MSBuild to enable/disable CPM on specific projects, parts of a directory tree, etc. But it requires someone to understand MSBuild's scripting language and hand edit the files appropriately. Though as far as MSBuild goes, the knowledge required is fairly basic (look at the docs for "well known properties" and the docs on conditions, and/or the docs on multi-level merging of directory.build.props&tarets files; the same info applies to directory.packages.props)

@JonDouglas
Copy link
Contributor Author

JonDouglas commented Jul 28, 2023

For more specifics, some SDKs such as Microsoft.NET.Test.SDK and the MAUI SDK are trying to use CPM. This is difficult for them today and for consumers using these SDKs because of all the implicit <PackageReference> that only SDK owners can really control.

This would also be a similar case for NuGet packages, SDKs, or libraries that make use of MSBuild targets/tasks to do similar mechanisms.

It would be nice for both SDK owners and SDK consumers to be able to incrementally use CPM rather than having to know deep MSBuild knowledge just to use the feature. That's a huge gap today in understanding.

@dotMorten
Copy link

My example: I maintain a set of class libraries. I want the class libraries to use lowest-necessary version, so users can choose any version from that and up.
However in my test/sample apps, I might want to use newer versions to better test the range, so want a different version there.
For example I might build a class library with Microsoft.WindowsAppSDK v1.0.0, but in my unit tests and sample apps, I want to use the latest version since they rely on newer functionality as well.
I've also found that implicit referenced libraries gets confused, like .NET MAUI wants to use WindowsAppSDK v1.3 as minimum in the sample app, but you might want to use 1.0 in the class library you're building/shipping.

But at the end of the day, there's just a small subset of nuget packages that every single project reference, and they should all be the same version - those are the ones I want to manage centrally - the rest I want to just manage in each project head.

So what I'd like to see:

  • Only manage packages defined in CPM, but allow other packages with version to be defined in project.
  • Centrally manage a package but allow certain projects to ignore that version and reference a different version.
  • Don't mess up implicitly referenced versions.

@craigktreasure
Copy link

This might deserve a separate issue, but I'd also like to add that it would be nice to be able to enable Transitive Pinning incrementally. For some large repos, it can be difficult to get all packages in a state where there are no conflicts. You can selectively enable it in certain parts of the tree (using Directory.Build.props for example), but it gets challenging when you have a lot of shared libraries.

This would be incredibly useful when addressing vulnerabilities in common packages like System.Drawing.Common or Newtonsoft.Json.

Something like the following would be extremely time saving and would prevent us from having to sprinkle direct dependencies all over to upgrade transitive dependencies:

<PackageVersion Include="System.Drawing.Common" Version="5.0.3" PinTransitively="true" />

@jeffkl jeffkl added Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. and removed Pipeline:Icebox labels Apr 3, 2024
@rayao
Copy link

rayao commented Jun 28, 2024

Comparing to centralized package management, I think a "centralized package version override" feature would be more useful.
Centralized package management forces PackageReference to remove Version attribute, the conversion is a tedious work, and most time (at least for my team) we just want a very limited set of dependencies to be managed, and the reason is in most time for security patch enforcement.
I'm not sure if my request is same as @craigktreasure's above, I'd suggest a "forced version override" mode, which doesn't require removal of Version attribute in project files, just simply pin a package to some version (if not opt-out by project file).

@zivkan
Copy link
Member

zivkan commented Jun 30, 2024

@jbennink
Copy link

jbennink commented Sep 6, 2024

@dotMorten

  • Only manage packages defined in CPM, but allow other packages with version to be defined in project.

@rayao

Centralized package management forces PackageReference to remove Version attribute, the conversion is a tedious work

This is what had me stumped. You can't adopt CPM unless all projects remove the "Version" from the package reference. Why!!!! It would be much more usefull to have the CPM version always override the Version in the project, and also have a VersionOverride option in the project for cases where it is absolutely neceessary to have a specific version.

Now I am faced with a "solution" consisting of 100 projects that I have to go by everyone to remove versions beofre repaping any possible benefits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area:RestoreCPM Central package management Functionality:Restore Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. Type:Feature
Projects
None yet
Development

No branches or pull requests

10 participants