Cannot pin NETStandard.Library = 1.6.0

[tpluscode]

Description

Similar to #2289, I seeming cannot install packages when I pin NETStandard.Library 1.6.0. This is required by AWS Lambda, but most recent Microsoft.* packages require version 1.6.1. I keep getting
the Paket may still find a valid resolution, but this might take a while message but I never waited long enough for it to finish.

Here's my intended dependencies file.

source https://www.nuget.org/api/v2/

nuget xunit >= 2.3 prerelease
nuget FakeItEasy
nuget FluentAssertions
nuget Microsoft.NET.Test.Sdk
nuget xunit.extensibility.execution >= 2.3 prerelease
nuget xunit.runner.visualstudio >= 2.3 prerelease
nuget Microsoft.AspNetCore.Mvc.Core
nuget Amazon.Lambda.Core
nuget Amazon.Lambda.Serialization.Json
nuget Amazon.Lambda.APIGatewayEvents
nuget Microsoft.AspNetCore.Server.Kestrel
nuget Microsoft.Extensions.Configuration.EnvironmentVariables
nuget Microsoft.Extensions.Configuration.FileExtensions
nuget Microsoft.Extensions.Configuration.Json
nuget Microsoft.Extensions.Logging
nuget Microsoft.Extensions.Options.ConfigurationExtensions
nuget AWSSDK.S3
nuget AWSSDK.Extensions.NETCore.Setup
nuget Amazon.Lambda.Logging.AspNetCore
nuget Amazon.Lambda.AspNetCoreServer
nuget NETStandard.Library 1.6.0

Repro steps

Use the above dependencies file and paket install

Expected behavior

Should resolve older versions of packages which don't require NETStandard.Library: >= 1.6.1

Actual behavior

It takes very long

Known workarounds

It is seemingly possible to pin all packages and their transitive dependencies but there are loads of them.

I also tried with groups but it keeps telling me that install fails because my project references two version of the NETStandard.Library package.

[cloudRoutine]

Did you try putting the AWS lambda packages in a different group?

[tpluscode]

I only tried putting the net standard library in a separate group. Would you put all Amazon.*, AWSSDK.* and the required Microsoft.* packages in a group?

[cloudRoutine]

I'd divide them based on the framework restriction you want to enforce, if you're fine with those using the higher versions then put them with it

[tpluscode]

Sorry, I don't follow. There is just one restriction: NETStandard.Library = 1.6.0. I tried like this:

source https://www.nuget.org/api/v2/

nuget xunit >= 2.3 prerelease
nuget FakeItEasy
nuget FluentAssertions
nuget Microsoft.NET.Test.Sdk
nuget xunit.extensibility.execution >= 2.3 prerelease
nuget xunit.runner.visualstudio >= 2.3 prerelease
nuget Microsoft.AspNetCore.Mvc.Core
nuget AWSSDK.S3
nuget AWSSDK.Extensions.NETCore.Setup
nuget Amazon.Lambda.Logging.AspNetCore
nuget Amazon.Lambda.AspNetCoreServer
nuget Amazon.Lambda.Core
nuget Amazon.Lambda.Serialization.Json
nuget Amazon.Lambda.APIGatewayEvents
nuget Microsoft.AspNetCore.Server.Kestrel
nuget Microsoft.Extensions.Configuration.EnvironmentVariables
nuget Microsoft.Extensions.Configuration.FileExtensions
nuget Microsoft.Extensions.Configuration.Json
nuget Microsoft.Extensions.Logging
nuget Microsoft.Extensions.Options.ConfigurationExtensions

group lambda
source https://www.nuget.org/api/v2/
nuget NETStandard.Library 1.6.0

And this fails with a different error:

Installation Errors :
Package NETStandard.Library is referenced in different versions in lambda-project.csproj (1.6 vs 1.6.1), check the lock-file.

Looking at the lock file it makes sense because paket resolved all those packages where NETStandard.Library (>= 1.6.1) and hence there is a mismatch

[cloudRoutine]

maybe you want strategy: min?
https://fsprojects.github.io/Paket/dependencies-file.html#Strategy-option

[tpluscode]

Well, I'd though about that and it worked once I put Microsoft.AspNetCore.Mvc.Core in both groups:

source https://www.nuget.org/api/v2/

nuget xunit >= 2.3 prerelease
nuget FakeItEasy
nuget FluentAssertions
nuget Microsoft.NET.Test.Sdk
nuget xunit.extensibility.execution >= 2.3 prerelease
nuget xunit.runner.visualstudio >= 2.3 prerelease
nuget Microsoft.AspNetCore.Mvc.Core

group lambda
source https://www.nuget.org/api/v2/
strategy: min
nuget Microsoft.AspNetCore.Mvc.Core
nuget NETStandard.Library 1.6.0
nuget AWSSDK.S3
nuget AWSSDK.Extensions.NETCore.Setup
nuget Amazon.Lambda.Logging.AspNetCore
nuget Amazon.Lambda.AspNetCoreServer
nuget Amazon.Lambda.Core
nuget Amazon.Lambda.Serialization.Json
nuget Amazon.Lambda.APIGatewayEvents
nuget Microsoft.AspNetCore.Server.Kestrel
nuget Microsoft.Extensions.Configuration.EnvironmentVariables
nuget Microsoft.Extensions.Configuration.FileExtensions
nuget Microsoft.Extensions.Configuration.Json
nuget Microsoft.Extensions.Logging
nuget Microsoft.Extensions.Options.ConfigurationExtensions

I expected this option to give me "ancient" versions of dependencie but it actually installed latest matching stuff. For example Microsoft.Extensions.Options could have landed 1.0.0-rc2-final but I actually got 1.0.2, which is good.

Is it that I mistook strategy for lowest_matching vide

Note, however, that all direct dependencies will still get their latest matching versions, no matter the value of the strategy option. If you want to influence the resolution of direct dependencies then read about the lowest_matching option.

?

[matthid]

Tbh paket is just not good for this scenario. I guess the resolver was not optimized for this scenario (where you have one condition which basically forces most packages to use an older version). But I think it's a really good test case...

[matthid]

And additionally if all packages have '>= 1.6.0' (which I guess they have) paket is finding a perfectly valid resolution. so this is probably more a nuget design flaw than anything else...

[cloudRoutine]

I finally got around to actually trying this myself, it only took 2m 2s for me to resolve this with the current alpha release of paket

paket.dependencies & resulting lockfile

@tpluscode is this what you wanted?

[cloudRoutine]

but if the behavior we want to have is rolling back direct dependencies listed in paket.dependencies that don't have a version number specified when another direct dependency is a transitive dependency of that first package but it has it's own constraint we roll back the package(s) without a constraint until they match, e.g

source https://www.nuget.org/api/v2/

nuget NETStandard.Library <= 1.6.0
nuget Microsoft.AspNetCore.Mvc.Core

shoould force Microsoft.AspNet.Core.Mvc.Core to roll back until version 1.0.3 the latest version that does not depend on netstandard.library where all of Microsoft.AspNet.Core.Mvc.Core's dependencies can also satisfy the constraints of Netstandard.library 1.6.0

(resolving these packages took 2 minutes, 36 seconds - ready.)

[matthid]

Just to note #2294 (comment) from @cloudRoutine is just a workaround for now. IMHO the resolver should be smart enough to be able to find something with default settings as well...

[matthid]

After #2307

source https://www.nuget.org/api/v2/

nuget NETStandard.Library <= 1.6.0
nuget Microsoft.AspNetCore.Mvc.Core

Locked version resolution written to C:\PROJ\paket.test\paket.lock
1 minute, 8 seconds - ready.

source https://www.nuget.org/api/v2/

nuget xunit >= 2.3 prerelease
nuget FakeItEasy
nuget FluentAssertions
nuget Microsoft.NET.Test.Sdk
nuget xunit.extensibility.execution >= 2.3 prerelease
nuget xunit.runner.visualstudio >= 2.3 prerelease
nuget Microsoft.AspNetCore.Mvc.Core
nuget Amazon.Lambda.Core
nuget Amazon.Lambda.Serialization.Json
nuget Amazon.Lambda.APIGatewayEvents
nuget Microsoft.AspNetCore.Server.Kestrel
nuget Microsoft.Extensions.Configuration.EnvironmentVariables
nuget Microsoft.Extensions.Configuration.FileExtensions
nuget Microsoft.Extensions.Configuration.Json
nuget Microsoft.Extensions.Logging
nuget Microsoft.Extensions.Options.ConfigurationExtensions
nuget AWSSDK.S3
nuget AWSSDK.Extensions.NETCore.Setup
nuget Amazon.Lambda.Logging.AspNetCore
nuget Amazon.Lambda.AspNetCoreServer
nuget NETStandard.Library 1.6.0

Locked version resolution written to C:\PROJ\paket.test\paket.lock
1 minute, 39 seconds - ready.

With the min workaround

strategy: min
lowest_matching: true

Locked version resolution written to C:\PROJ\paket.test\paket.lock
1 minute, 49 seconds - ready.

So that one is actually slower now :P