NuGet did not recognized package version conflict across projects

[chucklu]

Details about Problem

VS version (if appropriate):
Microsoft Visual Studio Professional 2019
Version 16.7.7

OS version (i.e. win10 v1607 (14393.321)):
win10 1909

Detailed repro steps so we can see the same problem

I will provide a git repository later according the issue id

[chucklu]

Please refer to repository https://github.com/ChuckTest/NuGet-10302
1.ConsoleApp1 reference ClassLibrary1
2.ClassLibrary1 reference Microsoft.Extensions.Configuration.Json 3.1.6 with System.Text.Json (>= 4.7.2)
3.ConsoleApp1 reference CsvHelper 12.1.2 with System.ValueTuple (>= 4.4.0)

The point is System.Text.Json (>= 4.7.2) depends on System.ValueTuple (>= 4.5.0)

When I reference CsvHelper 12.1.2 in ConsoleApp1, the package.config install System.ValueTuple 4.4 for me.
Actually it was supposed to install System.ValueTuple 4.5 for me, because ConsoleApp1-->ClassLibrary1-->System.Text.Json (>= 4.7.2)-->System.ValueTuple (>= 4.5.0)

[zkat]

This looks to me like the "nearest wins" rule, which means this is working as expected. Is that right, @nkolev92 ?

[nkolev92]

This is packages.config, not PackageReference.

packages.config is not transitive, so the ProjectReference from Console to Class Library doesn't pull in any packages.

If you tried the same set-up with PackageReference:

CLassLibrary-> Microsoft.Extensions.Configuration.Json 3.1.6
ConsoleApp -> CLassLibrary
ConsoleApp -> CVSHelper 12.1.2

I'd expect that 4.5.0 of System.Value.Tuple gets resolved.

In this case, 4.5.0 gets resolved because they are cousin dependencies. Basically they'd need to be part of the same subgraph to apply nearest wins, and that's usually going to be accompanied with a warning.

edit
You might see a few deleted comments, cause I drew the wrong graph :D Now it should be fine.

[nkolev92]

Basically to make it easier...think about it this way:

Console -> Library -> MECJ 3.1.6 -> STJ 4.7.2 - SV 4.5.0
Console -> CsvHelper 12.1.2 -> SV 4.4.0

They are not part of the same subgraph, so in a latter pass, we pick 4.5.0 over 4.40.

Console -> Library -> MECJ 3.1.6 -> STJ 4.7.2 - SV 4.5.0
Console -> Library -> SV 4.4.0
Console -> CsvHelper 12.1.2 -> SV 4.4.0

This would cause 4.4.0 to be selected, because Library explicitly downgrade SV to 4.4.0.

You also get a warning to help you with that in NU1605 (which is elevated to an error by default in SDK projects).

[chucklu]

I will get an msbuild warning when I try to rebuild the solution, the message is not clear and seems to be fixed dotnet/msbuild#608

2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2084,5): warning MSB3277: Found conflicts between different versions of "System.ValueTuple" that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.

I just wonder if the nuget can fix this automatically.

[chucklu]

I have created two branches for tests, it seems the different reference order make the auto bindingRedirect behave differently
https://github.com/ChuckTest/NuGet-10302/tree/class-library-first
https://github.com/ChuckTest/NuGet-10302/tree/console-app-first
Currently console app reference class library,
When in console-app-first mode, it means reference CsvHelper 12.1.2 in console app first, then reference Microsoft.Extensions.Configuration.Json 3.1.6 in class library.
When in class-library-first mode, it means reference Microsoft.Extensions.Configuration.Json 3.1.6 in class library first, then reference CsvHelper 12.1.2 in console app .

And at last, the bindingRedirect is different for these two mode. console-app-first mode will lose bindingRedirect for System.ValueTuple.
I am not sure if there is a bug of nuget, or the release policy is wrong for nuget.

https://www.nuget.org/packages/System.Text.Json/4.7.2
.NETFramework 4.6.1
System.ValueTuple (>= 4.5.0)

// packages\System.ValueTuple.4.5.0\lib\net47\System.ValueTuple.dll
// System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
And when I check the real dependency of packages\System.Text.Json.4.7.2\lib\net461\System.Text.Json.dll
// System.Text.Json, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
The version of System.ValueTuple is 4.0.2.0, which is mapped to nuget version 4.4
// System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51

[nkolev92]

@chucklu

When I compare the branches, ChuckTest/NuGet-10302@class-library-first...console-app-first, I see thjat in one the packages are installed and they aren't in the other one.

Maybe there's something that hasn't been pushed yet?

[chucklu]

Hi @nkolev92 ,
It seems the compare feature across branches of GitHub is broken.
ClassLibrary1/packages.config exists on both branches, and GitHub compare result shows it only exist on branch console-app-first.
https://github.com/ChuckTest/NuGet-10302/blob/console-app-first/ClassLibrary1/packages.config
https://github.com/ChuckTest/NuGet-10302/blob/class-library-first/ClassLibrary1/packages.config

I suggest you to clone the repository to local and compare the branches on local computer.
The correct compare result should as following:

By the way, the compare feature of GitHub is really horrible, I have already reported two other bugs for it. Now, a new bug emerged. I will not report this new bug to GitHub this time, just remember do not try to compare branches on web.

[nkolev92]

I can see the difference.

Can you please confirm the repro steps again?
Here's my takeaway

1. Create console app
2. Create class library
3. Add a reference from console app to class library.
4. Add CvsHelper 12.1.2
5. Add Microsoft.Extensions.Configuration 3.1.6 in class library

vs

1. Create console app
2. Create class library
3. Add a reference from console app to class library.
4. Add Microsoft.Extensions.Configuration 3.1.6 in class library
5. Add CvsHelper 12.1.2 in console app

[chucklu]

@nkolev92 Yes, the reproduce steps are correct. And the step 4 in first reproduce is "Add CvsHelper 12.1.2 in console app".
I did the above steps one by one through git commit, you might check the branch log to check the detail.
https://github.com/ChuckTest/NuGet-10302/commits/class-library-first
https://github.com/ChuckTest/NuGet-10302/commits/console-app-first

[nkolev92]

Hey @chucklu

Trying to follow those steps, I was not able to see the behavior you are observing.
I end up with different versions of packages installed.

When you install the packages, what's the Dependency Behavior you are selecting?

[chucklu]

@nkolev92 The library referenced by class library should be Microsoft.Extensions.Configuration.Json instead of Microsoft.Extensions.Configuration

[nkolev92]

Ok, following those instructions, I don't quite see the same thing as you.

I notice the slight different in binding redirects, but they are not missing.

Note that the binding redirects are applied at package installation time, so this is a design flaw of how binding redirects are handled in packages.config.

You can consider disabling NuGet's binding redirects and add https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection.

Note that because of this in PackageReference, NuGet does not handle the binding redirects.

[nkolev92]

cc @kartheekp-ms who's on hot seat and can help with the investigation further if necessary.

[chucklu]

@nkolev92 I tried again based on commit ChuckTest/NuGet-10302@a4d90e2 in my repository.
And I can still get the same result, when reference CsvHelper 12.1.2 in console app first, it will add the dependency System.ValueTuple 4.4 to console app. Then when I reference Microsoft.Extensions.Configuration.Json 3.1.6 in class library, it will skip the binding redirect of System.ValueTuple of console app.
I think the difference you encounter might be caused by the already exist package.config and app.config which generated beofre. You fogot to do "git clean" to clear the directory.
I suggest you to clone my repository and create a new branch based commit a4d90e2, and try reproduce it.

[kartheekp-ms]

I cloned https://github.com/ChuckTest/NuGet-10302 repo and turned-on verbose logging for MSBuild in Visual Studio.

This issue is related to dotnet/sdk#1897 issue as MSBuild encountered a conflict between 'Reference:System.ValueTuple' and 'Platform:System.ValueTuple.dll' during build time.

1>Task "ResolvePackageFileConflicts"
1>  Encountered conflict between 'Reference:System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL' and 'Platform:System.ValueTuple.dll'. Choosing 'Reference:System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL' because AssemblyVersion '4.0.3.0' is greater than '4.0.2.0'.
1>  Encountered conflict between 'Platform:System.ValueTuple.dll' and 'Reference:System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL'. Choosing 'Reference:System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL' because AssemblyVersion '4.0.3.0' is greater than '4.0.2.0'.
1>Done executing task "ResolvePackageFileConflicts".
1>Done building target "_HandlePackageFileConflicts" in project "ClassLibrary1.csproj"

2>Task "ResolvePackageFileConflicts"
2>  Encountered conflict between 'Reference:System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL' and 'Platform:System.ValueTuple.dll'. Could not determine a winner because 'Platform:System.ValueTuple.dll' has no file version.
2>  Encountered conflict between 'Platform:System.ValueTuple.dll' and 'Reference:System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL'. Could not determine a winner because 'Platform:System.ValueTuple.dll' has no file version.
2>Done executing task "ResolvePackageFileConflicts".
2>Done building target "_HandlePackageFileConflicts" in project "ConsoleApp1.csproj".

[nkolev92]

@kartheekp-ms

There are no SDK projects in this question, so the SDK issue is not relevant in this case.