6

I am having difficulty getting rid of the build warning:

warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved

specifically in .NET core projects.

In a full .NET framework project I would add some binding redirects so I googled around that issue and found this answer suggesting adding the following to the .csproj file:

<PropertyGroup>
  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
  <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>

I have done this but to no avail - I still get the build warnings. Anything else I can do?

Stewart_R
  • 13,764
  • 11
  • 60
  • 106
  • Please share at lease relevant parts of your project file and solution setup. (fyi .NET Core doesn't have binding redirects) – Martin Ullrich Aug 02 '17 at 20:14
  • @MartinUllrich Thanks for the response - what is it that you would like to see from the proj files? The project in question is [here](https://github.com/stewart-r/DlnaCore). I'm really struggling to understand how dependant assemblies get redirected in .net core without it? Is there some other mechanism I am unaware of - i;ve googled and googled and came up blank – Stewart_R Aug 02 '17 at 21:53
  • Actually - the branch in question is [this one](https://github.com/stewart-r/DlnaCore/tree/dev) – Stewart_R Aug 03 '17 at 08:12

4 Answers4

6

I had a look at your project and the problem seems to be a conflict with the versions that Rssdp was built against and the assembly version that the referenced System.Net.Http version (4.3.0) provides as compile-time reference.

This can be fixed by updating System.Net.Http to 4.3.2.

<PackageReference Include="System.Net.Http" Version="4.3.2"/>
Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • well that works but I still don't understand! :-) Rssdp references a version < 4.3.2 and another dependency references a version < 4.3.2 but if i explicitly reference a version higher than both of those .net core resolved it automatically?? I'm very grateful for your help in any event! Thank you – Stewart_R Aug 03 '17 at 10:08
  • The NuGet package version doesn't resemble the assembly version and they had problems with their versioning schemes and conflict resolution when used on full framework.. – Martin Ullrich Aug 03 '17 at 11:16
  • 1
    I dont really understand but that's definately not your problem! :-) Any suggestions for background reading on this would be very welcome but either way I am very grateful for your help in solving the issue. Thank you – Stewart_R Aug 03 '17 at 11:24
0

Run Update-Package via Package Manager Console, this will fix MSB3277, what it does it reinstall all the packages with highest version possible.

More info on official docs https://learn.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages

Aistis Taraskevicius
  • 781
  • 2
  • 10
  • 31
  • I'm not sure how I'd do that. That reference says _"For the dotnet CLI, the equivalent procedure is not required. In a similar scenario, you can restore packages with the dotnet CLI."_ My build server has no GUI, and `dotnet restore` is supposed to be done automatically with the build. – Auspex Oct 08 '19 at 14:06
  • Is your project .Net Core 2.0+? Also are you having this issue on the build server or locally ? Update-Package is packet manager cli command, which is part of nugget packet manager and should be available on the build server. – Aistis Taraskevicius Oct 09 '19 at 15:51
  • Yes, it's .Net Core 2.2.7. I'm not sure whether `Update-package` is available or not, but that reference says I _shouldn't_ be using it, given that my build server is using the dotnet CLI. – Auspex Oct 10 '19 at 13:05
  • Obviously things have changed in last 2 years since this answer was posted, it states its not required, not that it cannot or should not be used. Do you have control of your build server? What is the exact issue you are having, is your build server unable to build the solution due conflicting nuget package versions? – Aistis Taraskevicius Oct 10 '19 at 13:55
0

I had the same issue. Got several warnings on one of the projects. I updated all packages from the solution level and warnings went away. I used the Visual Studios for Mac to update the package. Right click the solution, then Update Nuget Packages.

0

Does any of you dependencies use <PrivateAssets>?

If project A has a private reference, and both the private reference and another reference requires some package X, but the private one requires a higher version of package X, then the assembly for project A will also require the higher version of package X. However you end up with a situation where any other project, e.g. project B, that references project A will only see the lower version of package X as a dependency - hence select the lower version of the assembly of package X to be copied to the output directory. The good news is that this DLL-HELL is detected at build time, where it sees that assembly projectA.dll requires a different projectX.dll than the one already designated as primary, and thus it logs some very unhelpful output about packageX being required by itself, which makes no sense... and gives up the build.

AnorZaken
  • 1,916
  • 1
  • 22
  • 34