Lock file contains netcoreapp1.1 dependencies instead of netstandard2.0

[kerams]

Description

Adding https://www.nuget.org/packages/Serilog.Sinks.Console/4.0.0-dev-00834 to a .NET Core 3.0 project does not reference the package's netstandard2.0 dependencies (as listed on Nuget) in the lock file but instead netcoreapp1.1

Repro steps

Clone https://github.com/kerams/rep, remove the lock file and do paket install.

Expected behavior

Serilog.Sinks.Console (4.0.0-dev-00834)
      Serilog (>= 2.8)

in the lock file.

Actual behavior

[matthid]

Why do you think we should prefer netstandard 2.0 here?
Can you point to the spec or NuGet behavior that would indicate otherwise?
Without looking up anything I'd say this is by design because usually you prefer 'the same framework' so netcoreapp1.1 is closer to netcoreapp3.0 than netstandard2.0.

[kerams]

Simply because I thought the goal was to prefer the implementation/standard with the largest API surface (thus requiring the fewest dependencies) while still being supported by the target framework. The highest .NET Standard version netcoreapp1.1 supports is 1.6, whose API surface, I assume, is a strict subset of netstandard2.0's. Therefore choosing the latter should be perfectly safe and could potentially result in a simpler lock file (as is the case above).

[forki]

I don't think 1.6 is strict subset of 2.0. But maybe ask @terrajobst on Twitter !? kerams <[email protected]> schrieb am Sa., 23. Nov. 2019, 10:12:

…

Simply because I thought the goal was to prefer the implementation/standard with the largest API surface (thus requiring the fewest dependencies) while still being supported by the target framework. The highest .NET Standard version netcoreapp1.1 supports is 1.6, whose API surface, I assume, is a strict subset of netstandard2.0's. Therefore choosing the latter *should* be perfectly safe and could potentially result in a simpler lock file. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3732?email_source=notifications&email_token=AAAOANE4OLGZ7CGWT2JEGCLQVDXXPA5CNFSM4JQZFXTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7RAEI#issuecomment-557781009>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOANFJQAR2HZ62Z4EEHPLQVDXXPANCNFSM4JQZFXTA> .

[kerams]

https://github.com/dotnet/standard/blob/master/docs/metaphor.md

Logically, every version of .NET Standard is an interface. Later versions extend the previous version, i.e. there are no breaking changes. Newer versions have all APIs that previous versions had:

[forki]

I don't think this is correct in regards of 1.6 kerams <[email protected]> schrieb am Sa., 23. Nov. 2019, 10:47:

…

https://github.com/dotnet/standard/blob/master/docs/metaphor.md Logically, every version of .NET Standard is an interface. Later versions extend the previous version, i.e. there are no breaking changes. Newer versions have all APIs that previous versions had: — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3732?email_source=notifications&email_token=AAAOANC3B4N5AXU34WGXQHTQVD32TA5CNFSM4JQZFXTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7RRZY#issuecomment-557783271>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOANG4JY6NPWHVQAQZFQTQVD32TANCNFSM4JQZFXTA> .

[kerams]

https://github.com/dotnet/standard/blob/master/docs/faq.md

Based on community feedback, we decided not to make .NET Standard 2.0 be a breaking change from 1.x. Instead, .NET Standard 2.0 is a strict superset of .NET Standard 1.6.

It looks pretty unambiguous to me :)

[forki]

Yes but things are never that easy. Read about the history of net461 and netstandard2. Starting point here: #3447 Microsoft claimed they were compatible. Even against all evidence. Until they retracted eventually. I think 1.6 and 2.0 is a different story. They are probably compatible. But is this really the problem here? kerams <[email protected]> schrieb am Sa., 23. Nov. 2019, 10:50:

…

https://github.com/dotnet/standard/blob/master/docs/faq.md Based on community feedback, we decided not to make .NET Standard 2.0 be a breaking change from 1.x. Instead, .NET Standard 2.0 is a strict superset of .NET Standard 1.6. It looks pretty unambiguous to me :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3732?email_source=notifications&email_token=AAAOANGQ5S64UPT3DKWSRYDQVD4HZA5CNFSM4JQZFXTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7RTMQ#issuecomment-557783474>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOANFY5ZRQ5RFC5KMDBYDQVD4HZANCNFSM4JQZFXTA> .

[forki]

I personally also think netstandard2 should be preferred over netcoreapp 1.

[kerams]

I think 1.6 and 2.0 is a different story. They are probably compatible. But
is this really the problem here?

It's important if the right target from the Nuget package's metadata is to be systematically chosen by finding the one which implements the highest .NET Standard version. The process could fall apart if there are breaking changes. Unless you just want to hard-code that netstandard2.0 takes precedence over netcoreapp1.1 when the project's target framework is > netcoreapp2.0?

[matthid]

I personally also think netstandard2 should be preferred over netcoreapp 1.

Last time I checked the process was specified as I mentioned above. This is not about personal preference ;) I'm happy to be corrected though.
Also this is not about netstandard1.6 and 2.0. The netcoreapp versioning is not related to the netstandard version. Any logic you might imagine is doomed to fail in the future.

[forki]

Specified? As in a real spec? Where?

[matthid]

You can check that nuget applies the same logic. Just add netcoreapp3 as project framework and netcoreapp1 and netstandard2 as package framework here: https://nugettoolsdev.azurewebsites.net/5.3.0/get-nearest-framework?project=netcoreapp3.0&package=netcoreapp1.1%0D%0Anetstandard2.0

If you want different behavior the fix is to ask the package authors to add a netcoreapp3 build to the package or remove the netcoreapp1 one

[forki]

I was asking for spec. Does such thing exists? Matthias Dittrich <[email protected]> schrieb am Sa., 23. Nov. 2019, 11:32:

…

You can check that nuget applies the same logic. Just add netcoreapp3 as project framework and netcoreapp1 and netstandard2 as package framework here: https://nugettoolsdev.azurewebsites.net/5.3.0/get-nearest-framework?project=netcoreapp3.0&package=netcoreapp1.1%0D%0Anetstandard2.0 If you want different behavior the fix is to ask the package authors to add a netcoreapp3 buipd to the package or remove the netcoreapp1 one — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3732?email_source=notifications&email_token=AAAOANDXGA5UVVYPASHPF2LQVEBD3A5CNFSM4JQZFXTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7SJKQ#issuecomment-557786282>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOANCT5JUZYO7D5GDUM6TQVEBD3ANCNFSM4JQZFXTA> .

[matthid]

when in doubt I consult https://docs.microsoft.com/en-us/nuget/reference/target-frameworks or the nuget source directly. Any deviation usually resulted in more pain in the past - with the exception of the compat table between frameworks (which is not as important as preferring same framework, which this issue asks to deviate from)

[matthid]

Or asked differently: What would the change actually gets us? The current behavior works and runs, doesn't it?

[forki]

Nuget source is not a spec. ;) Matthias Dittrich <[email protected]> schrieb am Sa., 23. Nov. 2019, 11:42:

…

Or asked differently: What would the change actually gets us? The current behavior works and runs, doesn't it? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3732?email_source=notifications&email_token=AAAOANF4OZRS4OZRRVXWUPTQVECK3A5CNFSM4JQZFXTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7SONY#issuecomment-557786935>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOANA6X5M7RR734LGXKUDQVECK3ANCNFSM4JQZFXTA> .

[matthid]

Nuget source is not a spec. ;)

Ok, but they clearly link that part of the source in their docs.

To elaborate with a different - more extreme - example. Consider a package with net10 and netstandard20. And you build for net48 (https://nugettoolsdev.azurewebsites.net/5.3.0/get-nearest-framework?project=net48&package=net10%0D%0Anetstandard2.0). In this scenario you (NuGet and Paket) would still prefer net10 because it is the SAME framework and netstandard20 would be framework "switch".

This is just how NuGet (and Paket) always behaved and package authors need to account for that when packaging their stuff.
There is basically no way to know for the package manager that the netstandard20 build has more APIs or would be more modern or anything, what would be the criteria?

[kerams]

Feature request for overrides in the Nuget client NuGet/Home#7416
Having this feature in Paket, at least in the form of overrides, could be attractive for some Nuget users.

[matthid]

Even if I would agree with the OP and would like to change this - which I clearly do not. What would be the criteria to switch to netstandard instead of preferring the same framework? Date of release of the framework? Version of the netstandard it implements?

Maybe once that is clear I can give some examples where this would be a bad idea in practice, which I think can be already given in the OP example: I just need to find one API available in netcoreapp1.1 and not in netstandard2.0 and then build a package using that API. Now if your project depends on it there is a real difference in behavior. I think such things exist as netcoreapp usually has some APIs very early.

[matthid]

IMHO NuGet/Home#7416 is not a valid example. This is just not how the system is designed. The author should have made a major version increase switching to M.E.F. and removed System.Configuration and old frameworks. Shipping different frameworks in a single nuget package with different API surfaces and dependencies like this is doomed to create problems if you don't know how the system works ;)

In any case my stand on this: Let the NuGet team figure it out if this is really a problem (which given only 2 comments on over a year probably doesn't think it is). If they change anything we can discuss on how to follow.