.Net 5 package resolution problems with some packages

[matthid]

@forki I noticed a problem on GitLab which basically boils down to paket (crashing with stackoverflow) having trouble to resolve:

group Build
   source https://api.nuget.org/v3/index.json
   nuget Fake.DotNet.Cli
   nuget Fake.IO.FileSystem
   nuget Fake.Core.Target

Paket 5.251.0 runs into the following 'conflict':

 Conflict detected:
  - System.Security.Cryptography.Cng 5.0.0-preview.8.20407.11 requested package Microsoft.NETCore.Platforms: >= 5.0.0-preview.8.20407.11 (preview)
  - System.Text.Encoding.CodePages 4.7.1 requested package Microsoft.NETCore.Platforms: >= 3.1.1
  - System.Security.AccessControl 4.7.0 requested package Microsoft.NETCore.Platforms: >= 3.1
  - System.Security.Principal.Windows 4.7.0 requested package Microsoft.NETCore.Platforms: >= 3.1
  - System.Runtime 4.3.1 requested package Microsoft.NETCore.Platforms: >= 1.1.1

I assume there are still some problems with corner case packages on .net 5. Any chance we can get this fixed? While locally and on other CI systems paket finds a solution, it still dances around downgrading lots of packages until it finally finds a solution and downgrades some packages which IMHO shouldn't need to be downgraded (like NuGet.Common and some others).

At the very least I need to know what I should say to users when this hits someone?

Anyway, I released 5.20.4-alpha.1642, so maybe someone here can test if that actually works better?

From fsprojects/FAKE#2544

[forki]

System.Security.Cryptography.Cng 5.0.0-preview.8.20407.11

where is that one coming from?

[forki]

NuGet.Packaging 5.7.0 requested package System.Security.Cryptography.Cng: >= 5.0.0-preview.3.20214.6 (preview)

lol what?

[forki]

Adding nuget Nuget.Packaging 5.6 works.

group Build
   source https://api.nuget.org/v3/index.json
   nuget Fake.DotNet.Cli
   nuget Fake.IO.FileSystem
   nuget Fake.Core.Target
   nuget Nuget.Packaging 5.6

[matthid]

So the problem is that we need to wait for a "real" stable net5 release and cannot use -rc releases even though Microsoft says they are "production-ready"?

[matthid]

So the "fix" would be to "whitelist" -rc as "stable" in Paket versioning semantics (at least that seems to be what Microsoft is doing in practice here)? Alternatively, we special case when a "stable" package depends on a "prerelease" package (though I always thought we do that already?)?

[matthid]

Contrary to what I wrote earlier the crash isn't specific to GitLab but it seems unixes in general. For example you can easily reproduce the crash in WSL 2 (Sorry, I confused myself there).

So while there is a 'workaround' and it finds a solution on windows the crash should still be investigated as the conflict here is not too complicated and I'd assume this indicates that a lot of other scenarios will crash as well.

[pchinery]

I have seen similar "conflicts" myself locally. It did not end in a crash (or I did not wait long enough), but the conflicht from above does not really sound like a conflict, as only "greater or equal" restrictions are given.

In my case, this is the conflict:

The process is taking longer than expected.
Paket may still find a valid resolution, but this might take a while.
  Conflict detected:
   - Dependencies file requested package Microsoft.Extensions.Configuration: >= 3.0 < 4.0
   - Microsoft.Extensions.Hosting 3.1.10 requested package Microsoft.Extensions.Configuration: >= 3.1.10

If it is likely that this is another problem, I'll open another issue for this. But at least in both cases, I can't see a version conflict from the information given here.

[Dolfik1]

@forki this issue should be fixed by #4059