Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

PackageReference conflict resolution craziness

See original GitHub issue

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.

Issue Analytics

State:
Created 5 years ago
Comments:6 (2 by maintainers)

Top GitHub Comments

1reaction

dsplaistedcommented, Jan 7, 2019

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.

0reactions

MattLavalleeMAcommented, Jan 8, 2019

@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.