Clean up some package dependencies

[pentp]

Clean up unnecessary transitive dependencies as nuget packages are always shipped with a single version value now.
Remove netstandard2.1 targets for projects where it doesn't provide any practical benefit.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

This shouldn't be done by non-infra team member. There can be more implications in package dependencies, which need to be verified for many other scenarios, including source build.

[ViktorHofer]

These are direct dependencies which are intentionally explicitly referenced, even if those would come in transitively via other dependencies.

[ViktorHofer]

This shouldn't be done by non-infra team member. There can be more implications in package dependencies, which need to be verified for many other scenarios, including source build.

Yes and no. I'm fine with some of these changes (i.e. the netstandard2.1 TFM drops might be OK) but the dependencies are explicitly more verbose as we prefer referencing direct dependencies explicitly.

[ViktorHofer]

@dotnet/area-infrastructure-libraries PTAL (I would like a second opinion on this one)

[pentp]

This shouldn't be done by non-infra team member. There can be more implications in package dependencies, which need to be verified for many other scenarios, including source build.

Yes and no. I'm fine with some of these changes (i.e. the netstandard2.1 TFM drops might be OK) but the dependencies are explicitly more verbose as we prefer referencing direct dependencies explicitly.

But what are the benefits of such explicit references? They are incomplete currently anyway.

[ViktorHofer]

But what are the benefits of such explicit references? They are incomplete currently anyway.

Fair point about completeness. We had discussions about adding an analyzer that would enforce that direct assembly references are referenced.

The general advantages of explicitly referencing direct dependencies are:

• Clear view of a project's direct dependencies (on top of the targeting pack).
• When a transitive dependency changes, the project in question isn't impacted.

[pentp]

Clear view of a project's direct dependencies (on top of the targeting pack).

In some context a complete (flat) view of dependencies could be useful, but so could a more distilled view or even just the minimum required. This also seems partially a tooling/UI limitation.

When a transitive dependency changes, the project in question isn't impacted.

Any transitive dependency removals would have to be considered a breaking change anyway - any number of packages/projects out there could depend on it transitively. And since all package versions seem to be updated in-sync since .NET 9, there can't be any version mismatches either.

[ViktorHofer]

Any transitive dependency removals would have to be considered a breaking change anyway - any number of packages/projects out there could depend on it transitively. And since all package versions seem to be updated in-sync since .NET 9, there can't be any version mismatches either.

I wasn't exclusively talking about public dependencies here. Yes, for shipping packages, changing the dependency graph is considered a breaking change. We still have a lot of projects in this repository that don't ship as NuGet packages: All .Private. assemblies and the shared framework assemblies. Those projects can and should change their references based on demand.

In some context a complete (flat) view of dependencies could be useful, but so could a more distilled view or even just the minimum required. This also seems partially a tooling/UI limitation.

Correct. As mentioned, we prefer a view of direct dependencies in the project file which end up as the actual assembly's
references. We should document that and enforce via an analyzer.

[Varorbc]

I've mentioned this before, but I really prefer transitive references around. It makes dependencies much cleaner and easier to manage. For instance, by doing this, we could cut down the explicit references to something like the Microsoft.Extensions.Hosting package by about 50%.

explicit references

transitive references

[ericstj]

I'm not sold on the value of this PR. Can you describe what issue this is fixing and how that impacts the end customer? What is the benefit the customer of these libraries will see by removing these?

As a customer of these packages - you don't need to manage the dependencies at all. The package manager does that for you.

It does have some impact on the maintainers of the libraries (EG the owners of Microsoft.Extensions.* and others). I can see how some folks might actually prefer to list their direct dependencies explicitly so they understand all the dependencies they have. Ideally we'd also have validation to let them know when there are unused dependencies - I could see value in a PR that does that.

I can see value in a change that is removing unused dependencies completely - but that would be a breaking change and require documentation.

I've mentioned before that there are actually good reasons to promote dependencies higher in the package graph - it reduces the number of round-trips NuGet needs to make on restore and it insulates the consumer from breaking changes, should any of its dependencies drop a package in a future version. Both of these are reasons for listing all dependencies.

[ericstj]

As I've mentioned I'm not sold on the value of this PR.

[ericstj]

Looks to me like this was added to make it possible to drop the BCL.AsyncInterfaces dependency. You'll need the owners of @dotnet/area-extensions-hosting to approve.