net47 moniker skips netstandard2.0 dependencies

[yaakov-h]

Description

When depending on Microsoft.Extensions.Configuration for net47, Paket skips transitive dependency Microsoft.Extensions.Configuration.Abstractions.

Repro steps

Please provide the steps required to reproduce the problem

1. Create paket.dependencies:

source https://api.nuget.org/v3/index.json
framework net47
nuget Microsoft.Extensions.Configuration

2. Run paket.exe update

Expected behavior

paket.lock indicates:

• a dependency on Microsoft.Extensions.Configuration 2.0
• a transitive dependency on Microsoft.Extensions.Configuration.Abstractions 2.0

Actual behavior

paket.lock indicates no transitive dependencies:

RESTRICTION: == net47
NUGET
  remote: https://api.nuget.org/v3/index.json
    Microsoft.Extensions.Configuration (2.0)

Known workarounds

Set framework to net47, netstandard2.0.

[forki]

@matthid isn't that correct behavior? I thought net471 is the first that is compatible with netstandard2.0

[yaakov-h]

Officially net461 and higher are compatible with netstandard2.0.

net471 is the first .NET Framework that is compatible with netstandard2.0 without any glue / type-forwarder assemblies.

[matthid]

duplicate of #2779
duplicate of #2764
duplicate of #2718
duplicate of #2705
duplicate of #2391

I thought net471 is the first that is compatible with netstandard2.0

Yes that is what I recall as well.

[yaakov-h]

I'm confused about that.

If I'm skim-reading it correctly, the issue is handling the facade/glue/forwarder assemblies.

Why does Paket need to deal with that? Visual Studio / MSBuild automatically handles that, even for "normal" assembly references.

[matthid]

@yaakov-h Yes it is easy to think that. I asked the same in #2391 to @0x53A and got #2391 (comment)
Which clearly shows that there are situations where people have issues if we allow the given scenario.

[yaakov-h]

That is true, but surely that edge case logic only applies to .NET Standard 1.5 and 1.6?

.NET Standard 1.4 and .NET Standard 2.0 always supported net461 as a minimum target. It's only .NET Standard 1.5 that required net462 and .NET Standard 1.6 that required net47 when using SDK 1.x.

[matthid]

If you agree that .NET Standard 2.0 is a super-set of .NET Standard 1.5 and 1.6 then your statement doesn't even make any sense to me. How can we even say that net461 supports/implements netstandard2.0 but not netstandard1.6. We don't support such crazy resolutions.

[matthid]

Honestly, we have no idea what we are doing - whatever we do it seems to be a bad idea. Feel free to open PRs and improve/discuss the situation - it is possible that we didn't get the details correctly yet...
But this whole situation feels like everything is just a big hack.

[yaakov-h]

everything is just a big hack.

Indeed 😞

Perhaps at the very least, we could introduce a warning or error when a package only supports a newer target framework that what the user has specified?

So in this case, since I'm requesting a .NET Standard 2.0 package but Paket thinks that this requires net471 or higher, I should get an error message that says I need to use an older package version, or upgrade my project to a newer target framework.

Or, perhaps Paket should only resolve the highest package version that matches is compatible with the framework directive, and display a warning/error if none can be found (e.g. if I had selected nuget Microsoft.Extensions.Configuration >= 2.0 instead).

[matthid]

I think we previously added a warning and people complained because a lot of meta packages are out there which do not support an actual framework. And we cannot really tell the difference. Also there are packages which are by design empty for some frameworks as the functionality is already part of the framework...

NuGet ecosystem is a mess. About your resolving suggestion: We don;t have the meta-information regarding supported platforms at resolution time and it would complicate everything a lot.
In reality the only sane way would be to not drop platforms in package updates, but people don't listen to us.

[yaakov-h]

Hmmph.

With all that considered, the workaround in the OP might actually be the most sensible solution 😞