Paket: NuGet library targeting only netstandard2.0 wont install to net461 project

[Gonnagle]

Description

When I'm trying to install a NuGet package that has only the netstandard2.0 folder to a project that targets net461, the package is added to the paket.references, but the reference is not being added in *.csproj.

As net461 should be implementing netstandard2.0 I'd assume to be able to use a library targeting netstandard2.0 without problems.

In my original issue I am in control of the internal NuGet library, so I could make it to target also net461, but ain't the key idea of the whole netstandard that I don't have to explicitly define all the targeted platforms?

Repro steps

1. Get the sample repo https://github.com/Gonnagle/paket-tests/releases/tag/paket-issue-2705-repro (paket pinned to version 5.92.0-beta003)
2. Run paket add MP3Sharp -p UberLibrary

Expected behavior

Paket adds the library as a reference to the project UberLibrary (import clause to the *.csproj with a condition matching framework net461).

Actual behavior

Result can be seen in this commit: https://github.com/Gonnagle/paket-tests/commit/56ea3dcdede62cca38c8bb5bd49c7d58978f580c

Paket adds the package to paket.dependencies, paket.lock and paket.referencies, but the *.csproj does not update (on some earlier version I think I was able to get the referencies, but with condition matching only netstandard2.0 and thus references were still missing in this project...)

Suggested solution

Update the library to target at least net471.

As @matthid points out the current stand is that first .net version "properly" implementing netstandard2.0 is net471 so upgrading to that is proposed if such packages are needed.

Other known workarounds

• As a really dirty hack the *.csproj could be changed manually... NuGet also seems to add the reference as expected.
• Update 2018-07-30: When using the new style csproj this doens't seem to be an issue (nuget dependencies are handled differently and no longer require changes to csproj in the first place...) (NOTE! Kind of a side effect and might not work on all cases)

[matthid]

See discussion in #2391

[trullock]

Are we any closer to a resolution on this?

[matthid]

I think the current silent agreement is that this is a wont-fix as long as nobody brings new evidence that changing this improves anything. From an objective perspective net461 DOESN'T support netstandard2.0 technically. The only way they made it work is that the SDK will just put the missing functionality alongside your application (which is basically a hack)

[trullock]

OK, my problem is sort of a mix of all these issues. I have a netstandard2.0 dependency (that i control) referenced by a net4.7 and/or 4.7.1 project via paket. paket install doesnt add it to the dependee project. Is that expected with the current state of things? Is that a new bug or related to this?

[matthid]

@trullock I feel like this is a new problem, please open a new issue with more details

[trullock]

Great thanks, will do

[Gonnagle]

@matthid so paket (+old project format) requires net471 for nugets released to target only netstandard2.0 to install?

Updated the original repro and played around a bit with the following conclusions (run paket add MP3Sharp -p UberLibrary -V "1.0.3" on solution root to test the outcome of the linked tags):

1. Original issue remains on the latest version of the paket (5.175.2): consuming-netstandard20-nuget-in-net461-updated
2. Switching to the new style csproj format seems to fix the issues (at least on the repro): consuming-netstandard20-nuget-in-net461-new-project-format
3. Switching to target net471 also seems to work as a workaround (even with old csproj format/project structure): consuming-netstandard20-nuget-in-net471

Added 2 and 3 as workarounds in the issue description

[matthid]

@Gonnagle Your analysis is almost correct:

1. Nothing changed in paket since this was initially discussed (actually we initially released this and reverted it as it broke people)
2. This is not entirely correct and only a sideeffect on the fact that we "forward" our resolution to "nuget". Your dependency resolution might still be impacted if dependency groups differ (But it is very likely you get a sound resolution)
3. net471 is not a workaround but the suggested solution. From our perspective it is the first full framework release which "properly" supports netstandard20 without any publishing msbuild hacks

[Gonnagle]

Thanks @matthid. Updated the first post to reflect these conclusions and posted a request for dotnet team to clarify in their documentation that net471 is actually the first framework to fully implement netstandard2.0: https://github.com/dotnet/standard/issues/514#issuecomment-409836573