Control assets flow for transitive packages

[nkolev92]

As a package consumer, I want to be able to control the assets flow for transitive packages.

Example:
Example
Project -> A.nupkg -> B.nupkg.

Sometimes, I don't want to be able to access Bs APIs in my project, because I don't want to effectively take a compile dependency on a package that I didn't explicitly add as one.
Additionally, when I upgrade A.nupkg, it's possible that B.nupkg is not a dependency anymore, so it'll break my project.

Effectively I want to say, B.nupkg ExcludeAssets=compile.

This is completely safe, and will not break the usage of package A.

Now if I was so concerned with not having B nupkg code in my project, I could elevate it to a top level dependency as a workaround, but that would mean I have to manage the versioning of B.nupkg right now, which defeats the purpose of transitivity.

The approach here is similar to the dependency exclusions concept of Maven, but a bit more granular.

//cc
@rrelyea

[rohit21agrawal]

what would you expect your project output to be when you pack it? would it list the resolved version of B and say Exclude="compile, runtime" ?

[nkolev92]

@rohit21agrawal
Yes, ideally.
Do you see any flaws with that?

My biggest concern here, is that I'm not sure what the language to express this intent in, would be,
and how to handle situations where B, is at the same distance from the project in 2 different direct packages.

Example:
Project -> A -> B
Project -> D -> B.

[rohit21agrawal]

if A has a runtime dependency on B, the consumer of Package X (produced as a result of packing the project) would be broken because he won't get compile/runtime assets from B even though A explicitly expressed B as it's dependency.

[nkolev92]

B would be packed with exclude compile, not exclude runtime though?

Let's sync up offline.

[nkolev92]

Synced up offline.

This shouldn't impact pack, in my opinion.
The project will not be referencing B nupkg directly anyways.

The primary feature here is to allow package consumers to more granular control over what flows in their project.
Ofc, if someone does exclude=runtime, it then gets tricky.
A project might not built or run correctly, but it's package might.

[uladz-zubrycki]

@nkolev92 Hi! Any progress on this?
I started cleaning my project packages and found out that assemblies from transitive nuget dependencies are referenced at compile time and that's obviously not a thing I expected it to be.
Would rather like to have a behavior described in this issue to be a default for every package I consume. So that transitive dependencies are there at runtime, but if I needed sth at compile time I'd have to explicitly add that package as a direct dependency.

There seems to be a sort of related discussion, but from the package author's point of view #6614

And another one dotnet/roslyn#22095

[nkolev92]

Hey @v-zubritsky

This feature needs a design in order to make progress on it, and it's not on our immediate backlog (think next 3 months).

I can't speak on any scheduling beyond that, but customer feedback is one aspect we use for prioritization.