Should We Move Towards a “Central Package Management First” Ecosystem?

NuGet Product(s) Affected

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

Current Behavior

Summary

Central Package Management (CPM) has been available for over two years, and it’s clear that many developers appreciate its functionality. However, there are still minor issues (“papercuts”) that could be addressed.

Problem

As more projects adopt CPM, especially newer ones, it’s worth considering whether the .NET ecosystem should encourage a “CPM-first” approach for all projects. This could simplify dependency management as projects grow in complexity. But is this the right direction for the community, or should we stick to the current mixed approach?

Proposal

One idea being floated is to explore ways for developers to “opt-in” or make project templates more “CPM-friendly.” This would allow CPM to become easier to adopt and, eventually, become the default over traditional <PackageReference>. The goal of this issue is not to take a stance on whether this transition should happen, but to gather feedback and community sentiment on the idea.

Context

CPM typically becomes valuable once a project reaches a certain level of complexity. However, some newer popular OSS .NET projects are using CPM from day one, and these projects seem to scale their dependencies more easily.

Request for Feedback

I’m opening this issue to track community input on whether moving towards a “CPM-first” future in .NET is something worth pursuing. Would appreciate thoughts, experiences, and 👍 from both early adopters and those using the traditional approach.

Next Steps: Based on community feedback, we can discuss what changes or improvements would be needed to encourage this transition or refine the CPM experience overall.

Desired Behavior

I don't think anything should happen. I am opening this as a dialog for the community to discuss what they'd like to see.

Additional Context

No response

NuGet / Home