/cc @matthid

we have:

System.Security.Cryptography.OpenSsl (4.4) - restriction: || (&& (>= dnxcore50) (>= netstandard1.6)) (&& (>= netstandard1.6) (< monotouch) (< xamarintvos) (< xamarinwatchos) (< xamarinios) (< xamarinmac))

isn't net462 supposed to be compatible to netstandard1.6?

Not yet. We are still at Tooling Level 1, so only netstandard1.5

I guess the problem I see is it's choosing the netstandard FSharp.Core package over the netfull for net462.

Maybe it's because it's labeled as All Frameworks for 4.1.17 ?

why are you pinning to 4.1.7?

Just to be clear it's 4.1.17

.If you're a library author aren't you supposed to choose the lowest version you can? Or is that advice wrong now?

the problem ist that version doesn't work with netcore/netstandard

The dependencies says netstandard1.6 and all frameworks. Is that wrong? Should that be unlisted then?

no idea tbh

Doesn't really matter, FSharp.Core 4.2.3 produces the same problem.

yes I think the FSHarp.Core is unrelated. What I wonder is why we have the following:

@matthid shouldn't this be filtered out?

Paket 5.91.0 does not have the issue, seems to start with 5.92.1.

yes that was when @matthid splitted the files. I assume it's related

what does paket why openssl say? (maybe we want an option to track only a particular framework in the future)

shouldn't this be filtered out

yes maybe

seems to start with 5.92.1

not sure why. I splitted the files but the observable behavior of nuget shouldn't have changed (I mean we basically should forward the same info)

should ;-)

Yes that path shouldn't exist after restricting to net462 ..

just took a quick look. looks like the new files are not filterd by the targetframework filter

• maybe one of the framework restriction simplifications is invalid
• or the framework restrictions of the nuget packages are not read in correctly
• something in delegating the restrictions in the resolver itself.

or yes the files are written incorrectly

the are all the same ;-)

but tbh the restriction in the lockfile looks aready fishy

that is another issue. the current issue is that we generate a files without filtering at all.

small correction. it was filtering, but since we didn't clear the list that was not really effective. Anyway new version is under way and should be available in a minute

ok 5.96.1 is available

and dotnet restore seems to work for your sample

you might need to clean obj and paket-files folders

🎸 you two rock

@haf I remeber you encountered probably the same error but cannot find the issue/pr. please try again