Open ghuntley opened 7 years ago
With 15.2 and 15.3, here's what I see:
PM> Install-Package ReactiveUI -version 8.0.0-alpha0034
Attempting to gather dependency information for package 'ReactiveUI.8.0.0-alpha0034' with respect to project 'App1', targeting 'MonoAndroid,Version=v7.1'
Gathering dependency information took 1.23 sec
Attempting to resolve dependencies for package 'ReactiveUI.8.0.0-alpha0034' with DependencyBehavior 'Lowest'
Install-Package : Circular dependency detected 'reactiveui 8.0.0-alpha0034 => System.Reactive 3.1.0 => System.Reactive.PlatformServices 4.0.0-preview00001 =>
System.Reactive 3.1.0'.
At line:1 char:1
+ Install-Package ReactiveUI -version 8.0.0-alpha0034
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Install-Package], Exception
+ FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
Time Elapsed: 00:00:01.5002768
PM>
The issue is that for some reason, System.Reactive 3.1.0 => System.Reactive.PlatformServices 4.0.0-preview00001
is happening. That should not be happening. The 4.x ones are not compatible with 3.x. As you can see from the PM output, DependencyBehavior 'Lowest'
is there, so it shouldn't be jumping ahead.
Just to add a quick bookkeeping item:
PackageReference
Preview
checkedReactiveUI -version 8.0.0-alpha0034
However when I installed the same package from the console, it worked fine. I also suspect a GUI bug at play here. I can't check again because the package was unlisted from https://www.nuget.org/packages/reactiveui.
Thanks again for filing this!
I see the circular dependency error when packages.config from both the UI and NuGet Console in VS. I do not see it when using PackageReference.
@JonDouglas can any additional steps you used to repro the difference between the UI and Console and share the output? They should behave the same.
System.Reactive
packages appear to have reversed dependency order between versions which is especially painful since the 3.x packages do not have an upper bound on the dependency ranges, which means that the circular combination is allowed.
System.Reactive.PlatformServices 4.0.0-preview00001 -> System.Reactive 4.0.0-preview00001
System.Reactive 3.1.0 -> System.Reactive.PlatformServices 3.1.0
When resolving packages NuGet does not attempt to look for other solutions if a circular dependency occurs, this is considered a package authoring error and it is usually better to fail with a helpful message there instead of potentially coming up with a very unexpected set of packages to workaround the problem automatically. Here you don't own these packages, so it isn't very helpful unfortunately.
@ghuntley I suggest updating ReactiveUI's nuspec to disallow the 4.x versions of the above packages. You could also move to >= 4.x, but the key here is to make sure that System.Reactive and System.Reactive.PlatformServices stay in sync.
<dependency id="System.Reactive" version="[3.1.0, 3.9999.0)" exclude="Build,Analyzers" />
<dependency id="Splat" version="2.0.0" exclude="Build,Analyzers" />
<dependency id="System.Reactive.PlatformServices" version="[3.1.0, 3.9999.0)" exclude="Build,Analyzers" />
Another workaround for users is to install System.Reactive.PlatformServices 3.1.0
first, then install ReactiveUI
.
@emgarten But why is it even considering a later version as valid in it's circular dependency order search? There's no circular dependency if you go with the "lowest" path... ?
It's also not just "PlatformServices," it's all of the original packages. They are now type-forwarding facades where the impl moved into System.Reactive
. Before System.Reactive
was just a meta-package that pulled in PlatformServices and many others.
Disallowing the 4.x version seems wrong as well since the whole purpose of the typefowarders is to allow libraries built with 3.x be used with Rx 4.x.
@onovotny answer to your first question: These packages are referencing system packages directly. This is causing it to try a higher version due to conflicts between the system packages.
We'd prefer to not invest in major changes in packages.config resolver changes...cost, danger, etc...
We understand that is troublesome here, but packages.config is not well designed for reversing dependency directions. Like many issues that customers are having with NuGet, we are trying to move the ecosystem to PackageReference. How does that sound?
Is there a way in the SDK to avoid this behavior? I'm using the SDK to install NuGet packages in a specific folder. I try to avoid the issue by installing the PlatformServices first, but that won't work. Rather I'd simply like to say to the API: Ignore the old way of resolution.
Details about Problem
This defect is quasi-blocking the release of
netstandard
edition of ReactiveUI.See https://github.com/reactiveui/ReactiveUI/issues/1413
We have a workaround but it involves asking people to change their visual studio configuration to use
PackageReference
instead ofpackages.config
as their resolver. I don't want to release without having this problem fixed because the amount of pain it will cause to our users and the maintainers telling them to RTFM/release-notes aspackages.config
is the default option in Visual StudioDetailed repro steps so we can see the same problem
See https://github.com/reactiveui/ReactiveUI/issues/1413
Ensure resolver is using
packages.config
PM> Install-Package ReactiveUI -version 8.0.0-alpha0034
💥
Change resolver to use
PackageReference
PM> Install-Package ReactiveUI -version 8.0.0-alpha0034
🎈 🎉 🎈
Same happens for other platforms (inc iOS, so please validate against all TFMs that ReactiveUI supports - see https://github.com/reactiveui/ReactiveUI/tree/develop/src)
Thank-you
@onovotny helped out with troubleshooting this early this morning and finding the workaround; thank-you Oren for taking the time out away from your family to help out.