[Feature Request] Support netproject.toml for Package Management in .NET

[JonDouglas]

NuGet Product(s) Involved

NuGet SDK

The Elevator Pitch

Rust (Cargo) and Python (Poetry) have adopted the TOML format for their package management files, simplifying project setup and dependency management. Go and Swift also use TOML-like concepts for managing dependencies, providing a cleaner and more readable way to handle build and package concerns.

.NET can evolve its package management format by introducing a nuget.toml netproject.toml file, allowing for a more modern and modular approach to dependency management. This file would clearly separate package management from project/solution configurations and other build concerns within highly organized toml tables, aligning with modern best practices. Or even aid in the idea of moving away from projects/solutions in the future to be less complex to beginners.

Benefits of nuget.toml:

Cleaner separation of concerns:

Decouples package management from project/solution files (csproj, sln), making it easier to manage dependencies across projects.

Simplified syntax and readability:

TOML is more human-readable and less verbose compared to XML, enhancing developer experience for managing dependencies.

Out-of-the-box support for advanced concepts:

The toml file could support more advanced features like CPM (centralized package management), dependency groups, and profiles, improving flexibility for larger, more complex projects.

[dependencies]
Newtonsoft.Json = "12.0.3"
NUnit = "3.12.0"

[dev-dependencies]
xUnit = "2.4.1"
StyleCop.Analyzers = "1.1.118"

[package]
name = "MyProject"
version = "1.0.0"
authors = ["Author Name"]

Additional Considerations:
There are countless opportunities to re-think pkg mgmt and all the modern things like analyzers, targets,

A migration path or coexistence with the existing csproj dependency structure should be considered to ensure developers can adopt toml without disrupting current workflows.

toml should be fully supported by the existing NuGet/MSBuild/etc ecosystems, allowing for seamless management of packages and dependencies alongside any build requirements.

Other random ideas:

[dependencies]
Newtonsoft.Json = "12.0.3"

[target-frameworks]
netcoreapp3.1 = { Microsoft.Extensions.Logging = "3.1.0" }
net5.0 = { Microsoft.Extensions.Hosting = "5.0.0" }
net6.0 = { Microsoft.Extensions.Logging.Console = "6.0.0" }

[runtime]
win-x64 = { WindowsSpecific.Library = "1.0.0" }
linux-x64 = { LinuxSpecific.Library = "1.0.0" }

[dependencies]
EntityFrameworkCore = "6.0.0"

[transitive-dependencies]
override = { Newtonsoft.Json = "12.0.3" }

[build-tasks]
pre-build = ["scripts/generate-version.ps1"]
post-build = ["scripts/deploy.ps1"]

[custom-targets]
clean = "dotnet clean"
publish = "dotnet publish --configuration Release"

[tools]
dotnet-ef = "6.0.0"
dotnet-sonarscanner = "5.2.1"

[environment]
ASPNETCORE_ENVIRONMENT = "Development"
DB_CONNECTION_STRING = "Server=localhost;Database=mydb;User Id=admin;"

[package-sources]
nuget = "https://api.nuget.org/v3/index.json"
private = "https://my-private-feed.local/api/v3/index.json"

[global]
sdk = "6.0.100"
required = true

All of this of course goes into a single file and isn't separated by nuget.config, .csproj, packages.props, etc. You can do it all from TOML.

Additional Context and Details

No response

[davidfowl]

Why would we want to decouple package resolution from the build?

[JonDouglas]

Why would we want to decouple package resolution from the build?

I apologize, I wrote this too quickly. I was more referring to a combined model. A name like netproject.toml or whatever would better represent the idea, not nuget.toml.

I am still an advocate for everything being driven from the current working directory rather than relying on a higher-level solution structure.