NuGet is restoring wrong version if referenced indirectly from lib

[forki]

Original issue by @pshrosbree fsprojects/Paket#2976

The attached projects shows an inconsisteny when referencing packages indirectly. Just run dotnet build in the app folder and see it fail with NU1608:

The problem is the following. In the lib project we explicitly select Microsoft.Data.Services.Clientversion 5.8.3 fornet461, but this is just ignored during the build an NuGet decides to just use 5.8.2` instead. This introduces a version conflict. Note: NuGet is overriding my manual settings!

version.zip

WORKAROUNDS

While this behaviour leads to very weird errors, there are 2 workarounds:

a) go to lib folder and use <TargetFrameworks>netstandard2.0;net461</TargetFrameworks>
b) go to app folder and add explicit <PackageReference Include="Microsoft.Data.Services.Client" Version="5.8.3" />

[forki]

what does priority:1 mean?

[enioluwas]

Bumping this issue. This is incorrect behavior and provides no hints at resolution. The workarounds listed here are not solutions and are not sustainable when using centrally managed package versions.

[zivkan]

The original issue creator was misreading NU1608 message (which is a warning, by the way, it's only displayed as an error if your project opt-in to warnings as errors).

The message is saying that there's a package, Microsoft.Data.Services.Client that has a dependency on package Microsoft.Data.OData version =5.8.2. Note that most packages list dependencies as versions >=, but this one says =. Hence when the lib project specifies version 5.8.3, that no longer meets the first package's dependency version range. Hence the warning. But NuGet is using 5.8.3, just like the project requested.

There is no "one resolution for all scenarios". Maybe the package that specified an overly restrictive dependency version range is actually safe, so you can either stop treating all warnings as errors, and ignore the warning. Or you can use NoWarn to stop warning about NU1608.

What is more common, is for packages to list the version range as [1.2.3, 2.0.0), to effectively say "any version 1.x". If a project (or a second package in the graph) tries to bring in version 2.x or higher, then the first package might fail due to API breaking changes. Of course, not all software follows Semantic Versioning strictly (even NuGet itself does not), so maybe 5.8.2 and 5.8.3 actually do have breaking changes. In an API-incompatible scenario, there is no simple solution. Either you have to select different versions of other packages until you find a combination that all have compatible versions, or you need to have a multi-process application with inter-process communication, where each process uses a different version of the incompatible package. Sometimes .NET Framework App Domains, or .NET (Core) AssemblyLoadContexts can be used to load multiple versions of the same assembly in the same process, but from what I've heard from people working on large plug-in applications is that it's very unreliable and prone to crashing the process. Much safer and "easier" to do multi-process IPC/RPC instead.

In my opinion, this issue, as it's written, should be closed as the statement that NuGet was restoring the wrong version is incorrect. Maybe the NU1608 docs should be improved to mention NoWarn. @enioluwas brings up an interesting point about how easy this is with Central Package Management (I'm assuming with transitive pinning enabled) (fyi @jeffkl).

[enioluwas]

Thanks for the response @zivkan, I agree with your assessment that this is not incorrect behavior, as Nuget is not restoring the "wrong" version, it's just that, at least in my case, a package is being resolved to a version higher than the minimum specified by another package that references it, both of which my app depends on. This is what is emitting the NU1608 warning. For packages A and B this is what it looks like:

Package A (1.0) -> Package B ( >= 4.0)
Project C -> Package B (5.0) & Package A (1.0)

As you called out, with central package management, it's easy to run into this, and the workaround can snowball into extensive version overrides/NoWarn tags in all the affected projects. Suppressing the warning globally works of course, but I would rather have an easy way suppress this warning only for Package B and its transitive references, since I know Package B is fully backwards compatible. However I think this issue points out that there's no easy way to do that right now.

[nkolev92]

Team Triage: Closing the original issue as we do not think there's a bug in this scenario.

@enioluwas Please feel free to create a new issue for any problems you might have that aren't represented.

[ghost]

Issue is missing Type label, remember to add a Type label