-
Notifications
You must be signed in to change notification settings - Fork 525
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lock file has incorrect .NET framework lock #462
Comments
Mhm the nuspec specifies the net40 restriction. See:
Nuget.exe will still install Json.Net.dll - strange. |
Ok, after rereading #140 (comment) and remembering disucssion with @agross I now think we need to do the same framework inheritance strategy as in the file referencing algorithm. |
Yeah that was my thought - net40 should fall back to any higher FWs as well unless specified elsewhere. |
I think that this was the root cause of #448 as well. |
It's actually much more complicated than I thought, but I'm starting to work on it... |
:-( sorry! |
/cc @cdrnet |
the new lockfile looks like that:
|
The Lockfile for MathNet.Numerics looks like that:
|
Great, that looks exactly like what I intended in the MathNet.Numerics nuspec! |
please test 0.20 alpha - it's a huge change |
awesome :-) will check shortly :-) |
Just tried using the latest v20 alpha (6) and it works fine. Great stuff. |
I've just tried with v20 alpha 7 as well, with a package with even more complicated framework groups: MathNet.Numerics.FSharp-v3.3.0 (sorry! - ah, and yes, the next version will migrate to the new FSharp.Core NuGet package)
The intention of these groups is to have the MathNet.Numerics dependency in all cases, and the FSharp.Core dependency everywhere except .Net3.5 <= x < .Net 4.0. The group without a target framework acts as fallback where none of the groups is inherited by the current target. Now, with v20alpha7 the dependencies file
leads to the lock file
The lock on TaskParallelLibrary is now perfect, but to my understanding the MathNet.Numerics dependency should not have any framework constraints, or at least the >=net40 one dropped? |
Hm, maybe I better simplify these constraints instead, they are way too complicated ... |
Yes I thought about that case. Thanks for giving a test case. Will try to solve that. |
now gives:
|
seems there is still an issue with FSharp.Core.Microsoft.Signed!? |
Also seen that Humanizer isn't working getting referenced on the latest alpha. Looking at the package, it has a single folder in the lib folder: |
Isaac, can you please create a repro sample and open a new issue. I tried to reproduce, but Humanizer works fine for me. |
Sure. Let me remove the package completely and redownload it first. |
Bizarre. Just redownloaded it and it came down fine without %2B. Sorry. |
Create a paket.dependencies file as follows: -
The lock file generated looks like this: -
Notice the net40 restrictions on a number of dependencies. On a brand new FSharp Class Library (using net45), these are not available for consumption within code. For example, for Newtonsoft.Json, the only node in the .fsproj file is: -
If you remove the net40 from the lock file and then do a
paket install --hard
, everything works fine. You get multipleWhen
elements in the project file, one for each version made available by the dependency.The text was updated successfully, but these errors were encountered: