PackageReference conflict resolution craziness

[joshmouch]

I'm seeing issues with package versioning of transient packages using the PackageReference model. I found this entry in the build log, and this seems like a bug to me. A nuget package requires version 4.3.3, but then dotnet SDK grabs 4.2.0.0 because it's greater than 4.1.1.2? That doesn't make sense to me.

Is it a bug?

1>  C:\Program Files\dotnet\sdk\2.1.403\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(41,5): message 

NETSDK1041: Encountered conflict between 'Platform:System.Net.Http.dll' and 'CopyLocal:C:\Users\Joshua\.nuget\packages\system.net.http\4.3.3\lib\net46\System.Net.Http.dll'.  

NETSDK1033: Choosing 'Platform:System.Net.Http.dll' because AssemblyVersion '4.2.0.0' is greater than '4.1.1.2'.

If I go to that first folder and look at both the file and product versions, they are 4.6.25707.1.

[livarcocc]

@dsplaisted can you take a look and explain how conflict resolution works in this case?

[joshmouch]

I tried adding a direct reference to System.Net.Http so that the reference wasn't transient. I get a similar message.

Looking at the project.assets.json, I see that these values are all as I would expect. They point to version 4.3.3 or 4.3.4.

[joshmouch]

@dsplaisted Any thoughts? I think I could go in and manually add some assembly redirect bindings to the app.config to get around this, but I'd rather not. The project is huge, and that'd take days, I think.

[MattLavalleeMA]

I saw this not too long ago myself... There is an Assembly Version conflict in the VS build extensions that causes conflicts for any .NET Framework (Full) project that references System.Net.Http (which is just about everything these days). If you look here:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib

(Or whatever Edition you're using after \2017)

... you'll see that the System.Net.Http that's there has a higher Assembly Version than any that's otherwise available, and once netstandard 2.0 is indirectly leaked into your .NET Framework project, there's little recourse. Read more about it here: https://github.com/dotnet/corefx/issues/28833 . The only workaround is include an explicit reference and add that "ExcludeAssets" flag to every single project in the solution.

-Matt

[dsplaisted]

Messages in the log file about assembly version conflicts don't generally mean there's a problem. More or less, it simply means that there are references to different versions of the same library, and it needs to choose the best one.

Trying to understand what is happening can be further confused because there are a bunch of different version numbers a library can have. The NuGet package version, assembly version, and file version can be (and in some cases are) all different.

If you can enable automatic binding redirects in your projects, you should generally not have to worry about all of this. Automatic binding redirects aren't supported for classic ASP.NET projects, so you may need to add a bunch of binding redirects to your web.config explicitly (which VS will do for you if you double-click the right warning in the error list).

Alternatively, if you are able to target .NET 4.7.2 or higher, I believe that most or all of these conflicts (and hence binding redirects) should go away.

FYI @joperezr in case you have more to add.

[MattLavalleeMA]

@dsplaisted IIRC, with a downlevel target framework (i.e., 4.6.2), build won't copy the transient dependency and you get a runtime error on deployment. In a large solution environment with broadly-shared dependencies, it's non-trivial to upgrade the target framework of a given library.