Supplied by platform design

[nkolev92]

Prototype in https://github.com/NuGet/NuGet.Client/tree/dev-nkolev92-suppliedByPlatform
Related: NuGet/NuGet.Client#5919

To get dummy values from prototype, set AddDummyPrunedPackageReferences to true.

[dsplaisted]

It doesn't look like the spec explicitly states whether pruned packages will be downloaded at all. It would be good to explicitly never download pruned packages. Some vulnerability scanners look at the global packages folder, so this would ensure that those scanners wouldn't have false positives for pruned packages.

[nkolev92]

It doesn't look like the spec explicitly states whether pruned packages will be downloaded at all. It would be good to explicitly never download pruned packages. Some vulnerability scanners look at the global packages folder, so this would ensure that those scanners wouldn't have false positives for pruned packages.

Apparently I only had that in the summary.

This helps avoid downloading unnecessary reference and implementation packages

I'll add that explicitly in the rest of the spec as well.

[nkolev92]

Pushed some more changes to the spec based on the feedback.
There is a limitation with transitive shared frameworks. Not sure if we have an automatic solution for that.

[ericstj]

Honestly I've only ever seen folks complain when they get transitive shared frameworks. It's often accidental and it breaks deployment -- @dsplaisted what if the SDK encouraged people to make them direct?

IOW if the result of a restore or resolving project references changed the shared framework of the project the SDK would warn the user and ask them explicitly reference that framework.

[dsplaisted]

I'm wary of changing that behavior, because we don't know how many people we aren't hearing from who are relying on it (knowingly or not).

With respect to the supplied by platform design, I think it would probably be OK to only consider the direct framework references.

[ericstj]

What if we made it just a warning:

1. When transitive framework was brought in after restore.
2. We can see that the project has packages that overlap with that framework.
3. Warn that those packages could be dropped by directly referencing the framework.

[nkolev92]

I like that idea.
I added it in future possibilities.

[jaredpar]

@ericstj would these be specified by the individual targeting packs or the SDK as a whole?

[ericstj]

Today this information already ships in the individual targeting packs. @dsplaisted doesn't think that NuGet nor the SDK can directly consume it from here since they will not be available prior to restore, so the SDK build would need to capture them and store locally - similar to what it does with "KnownFramework" information.

However nothing should prevent other components specifying these, so long as they can specify them before restore. IOW they can come from user files and SDKs but not packages.