Skip to content
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

Paket has trouble resolving .NET Core dependency lists #1610

Closed
dsyme opened this issue Apr 14, 2016 · 7 comments
Closed

Paket has trouble resolving .NET Core dependency lists #1610

dsyme opened this issue Apr 14, 2016 · 7 comments
Labels

Comments

@dsyme
Copy link
Contributor

dsyme commented Apr 14, 2016

Description

I've been trying to use Paket to resolve the kind of dependency listings we're seeing in project.json files for compiling F# .NET Core components. I'm finding that Paket rarely succeeds in resolving these dependency lists.

Repro steps

Create a paket.dependencies for this dependency listing, taken straight from this project.json

Expected: the dependency list resolves OK in reasonable time

Actual: I aborted the operation after about 8 minutes, with this log

@tsibelman
Copy link
Contributor

I think that in case you had defined a framework version in your paket.dependency it would work faster

@forki
Copy link
Member

forki commented Apr 14, 2016

Thanks for reporting.

If the resolver needs that longer it usually means there is no valid
resolution. Paket is much more restrictive about that. But I assume there
still new things to discover here...

@forki forki added the bug label Apr 14, 2016
@forki
Copy link
Member

forki commented Apr 14, 2016

mhm. even with strategy:min (which is NuGet's default) it doesn't find a valid resolution in a short timespan.

source https://www.myget.org/F/dotnet-core/api/v3/index.json
source https://www.nuget.org/api/v2/
strategy: min

I assume there is in fact no valid resolution (looks like one of packages needs System.Compression and there is only a RC3 version of it and that's incompatible to other stuff).

If we open the version restrictions like the following then paket has no issues to find a valid resolution:

source https://www.myget.org/F/dotnet-core/api/v3/index.json
source https://www.nuget.org/api/v2/

nuget Microsoft.NETCore.Platforms prerelease
nuget NETStandard.Library prerelease 
nuget System.Collections.Immutable prerelease
nuget System.Diagnostics.Process prerelease
nuget System.Diagnostics.TraceSource prerelease
nuget System.Linq.Expressions prerelease   
nuget System.Linq.Queryable prerelease   
nuget System.Net.Requests prerelease  
nuget System.Reflection.Emit prerelease  
nuget System.Reflection.Emit.ILGeneration prerelease 
nuget System.Reflection.Metadata prerelease
nuget System.Reflection.TypeExtensions prerelease   
nuget System.Runtime.InteropServices prerelease 
nuget System.Runtime.InteropServices.PInvoke prerelease
nuget System.Runtime.Loader prerelease
nuget System.Security.Cryptography.Algorithms prerelease
nuget System.Security.Cryptography.Primitives prerelease 
nuget System.Threading.Tasks.Parallel prerelease 
nuget System.Threading.Thread prerelease    
nuget System.Threading.ThreadPool prerelease  
nuget Microsoft.DiaSymReader.PortablePdb prerelease 
nuget Microsoft.DiaSymReader prerelease 

image

@dsyme
Copy link
Contributor Author

dsyme commented Apr 14, 2016

OK, thanks. I'll close for now. I somehow suspect these might indicate recurring problems, where people take an existing project.json and try to use Paket over the same dependencies.

@dsyme dsyme closed this as completed Apr 14, 2016
@dsyme
Copy link
Contributor Author

dsyme commented Apr 14, 2016

@forki Just to mention that although the resolution did go through, it resolved to a bunch of packages using the netstandard1.0, netstandard1.3 and netstandard1.5 monikers, which Paket doesn't yet understand.

So a big 👍 to adding support for the netstandard monikers :)

@forki
Copy link
Member

forki commented Apr 14, 2016

Yeah we will add that. And next week they will make that obsolete again
like they did with DNX ;-)

Just kidding.
Obviously.
I hope.

;-)

@dsyme
Copy link
Contributor Author

dsyme commented Apr 14, 2016

@forki I think netstandard is going to stick.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants