[.net] Found conflicts between different versions of the same dependent assembly that could not be resolved

When I clean and then build my solution that has several projects, the output window reports that the build succeeded. However, when I view the Error List Window, it shows me this warning:

Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed. C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets

When I double-click this message, it opens the C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets file but I don't understand anything in it.

I am using Visual Studio Express 2013 for the Web.

How do I find out what's wrong and with which DLL and how do I then make the warning go away?

Please note that I solved this problem by putting the AutoGenerateBindingRedirects right after the TargetFramework in the csproj file:

<TargetFramework>net462</TargetFramework>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>

Run Update-Package command via Package Manager Console

This will fix MSB3277, what it does it reinstall all the packages and all related assemblies they come with to the highest version possible. It is also possible to update just specific package. Or downgrade after update if wanted, this fixed issue for me few times it came up. Depending on how many nuget packages you have, this process may take few minutes.

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

I'm using Visual Studio 2017 and encountered this when I updated some Nuget packages. What worked for me was to open my web.config file and find the <runtime><assemblyBinding> node and delete it. Save web.config and rebuild the project.

Look at the Error List window. You'll see what looks like a massively long warning about binding conflicts. Double-click it and it will automatically recreate the <runtime><assemblyBinding> block with the correct mappings.

VS 2017, MVC project

I don't know why, but for me, the solution for this issue was to remove an out parameter from a model method signature that was called from the controller action method. that is very strange behaviour but that was the solution to my problem.

I changed the MSBuild verbosity to Diagnostic.but couldn't find where the problem was so according to the answers above I had this code in app.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
<sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="XbimXplorer.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>

So I just changed the first System, Version from 4.0.0.0 to 12.0.0.0 and my project worked.

I could solve this installing Newtonsoft Json in the web project with nugget packages

You could run the Dotnet CLI with full diagnostic verbosity to help find the issue.

dotnet run --verbosity diagnostic >> full_build.log

Once the build is complete you can search through the log file (full_build.log) for the error. Searching for "a conflict" for example, should take you right to the problem.

and how do I then make the warning go away?

You are probably going to have to reinstall or upgrade your NuGet packages to fix this.

Reiterating one of the comments from @elshev Right click on the solution -> Manage NuGet packages for solution -> Under Consolidate you can see if there are different versions of the same package was installed. Update the packages there. The conflict error is resolved.

eta: There's a killer article on this stuff by SO's own @Nick Craver that you should read

While the other responses say this, they don't make it explicit, so I will....

On VS2013.2, to actually trigger the emission of the cited information, you need to not read the message, which says:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.

This is incorrect (or at least it was for some versions of Visual Studio - it seems to be OK on an up to date VS2015 Update 3 or later). Instead turn it to Diagnostic (from Tools->Options->Project and Solutions->Build and Run, set MSBuild project build output verbosity), whereupon you'll see messages such as:

There was a conflict between "Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" and "Newtonsoft.Json, Version=6.0.5.17707, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed".

• "Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" was chosen because it was primary and "Newtonsoft.Json, Version=6.0.5.17707, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" was not.

Then

• Ctrl-Alt-O to go to Build output window
• search for "was chosen" to find the drilldown.

...And yes, for those looking at the detail of the [diagnostic] message, it was news to this ignoramus that there's a convention in town whereby all 6.x versions are, internally Assembly Version 6.0.0.0, i.e. only the SemVer Major component goes into the Assembly Version :)

As stated in dotnet CLI issue 6583 the issue should be solved with dotnet nuget locals --clear all command.

Run msbuild Foo.sln /t:Rebuild /v:diag (from C:\Program Files (x86)\MSBuild\12.0\bin) to build your solution from command line and get a bit more details, then find the .csproj. that logs the warning and check its references and references of other projects that use the same common assembly that differs in version.

Edit: You can also set the build verbosity directly in VS2013. Go to Tools > Options menu then go to Projects and Solutions and set MSBuild verbosity to Diagnostic.

Edit: Few clarifications as I just got one myself. In my case warning was due to me adding a reference using Resharper prompt as opposed to the Add Reference dialog, which did it versionless even though both v4 and v12 are available to choose from.

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework" />

vs

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework, Version=12.0.0.0, ..." />

In the MSBuild log with /v:diag verbosity it looked like the following. giving details which two references conflicted:-

  There was a conflict between 
  "Microsoft.Build.Framework, Version=4.0.0.0, ..." and 
  "Microsoft.Build.Framework, Version=12.0.0.0, ...". (TaskId:16)

      "Microsoft.Build.Framework, Version=4.0.0.0, ..." was chosen because it was primary and 
      "Microsoft.Build.Framework, Version=12.0.0.0, ..." was not. (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=4.0.0.0, ..." 
      [C:\...\v4.5.1\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v4.5.1\Microsoft.Build.Framework.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v4.5.1\Microsoft.Build.Framework.dll". (TaskId:16)
              Microsoft.Build.Framework (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=12.0.0.0, ..." 
      [C:\...\v12.0\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v12.0\Microsoft.Build.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

          C:\...\v12.0\Microsoft.Build.Engine.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.Engine.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3277: 
Found conflicts between different versions of the same dependent assembly that could not be resolved.  
These reference conflicts are listed in the build log when log verbosity is set to detailed. 
[C:\Users\Ilya.Kozhevnikov\Dropbox\BuildTree\BuildTree\BuildTree.csproj]

If you made any changes to packages -- reopen the sln. This worked for me!

Changing the build verbosity in visual studio will help to point in the right direction. Follow the below steps to change verbosity in VS

1. Go to Tools->Options menu in VS
2. Open Projects and Solutions->Build and Run
3. Change the value of the MSBuild project build output verbosity. Pick one from Quiet, Minimal, Normal, Detailed and Diagnostic

Check the output window(Ctrl+Alt+O) in VS to see the changes in the build log.

I followed the advice of several of the responses here to figure out what was wrong, but none of the answers seemed to explain how to fix it. My issue was that one reference required a different version of a second reference. So Newtonsoft was at version 6, but some other DLL wanted 4.5. Then I upgraded Newtonsoft as one of the other answers suggested and that made things worse.

So I actually downgraded my Newtonsoft install and the warning went away (VS 2017):

Right click References in the solution explorer and select Manage NuGet Packages... Under the "Installed" tab, find Newtonsoft (or whatever your conflict is) On the right side, a dropdown appears next to "Version" that you can change to older versions. It wasn't obvious to me that this dropdown could be used to downgrade.

I just ran into this and the problem after switching a package from nuget to locally referenced dlls. The issue was old runtime binding stuff in app.config.

As per the other answers, set the output logging level to detailed and search there for conflicts, that will tell you where to look next.

In my case, it sent me off in a few directions looking for the source of the references, but in the end it turned out that the problem was one of my portable class library projects, it was targeting the wrong version and was pulling its own version of the references in, hence the conflicts. A quick re-target and the problem was solved.

I found that, sometimes, nuget packages will install (what I'm guessing are) .NET Core required components or other items that conflict with the already-installed framework. My solution there was to open the project (.csproj) file and remove those references. For example, System.IO, System.Threading and such, tend to be added when Microsoft.Bcl is included via some recently installed NuGet package. There's no reason for specific versions of those in my projects, so I remove the references and the project builds. Hope that helps.

You can search your project file for "reference" and remove the conflicts. If they're included in System, get rid of them, and the build should work. This may not answer all cases of this issue - I'm making sure you know what worked for me :)

Example of what I commented out:

<!-- <Reference Include="System.Runtime, Version=2.6.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> -->_x000D_
  <!-- <HintPath>$(SolutionDir)packages\Microsoft.Bcl.1.1.9\lib\net40\System.Runtime.dll</HintPath> -->_x000D_
  <!-- <Private>True</Private> -->_x000D_
<!-- </Reference> -->

I can only support further Ruben's answer with a comparison between the two messages displayed:

and the message:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.

So, Ruben's right—this is just not true. There are no conflicts whatsoever, just a missing assembly. This is especially boring when the project is an ASP.NET application, since the views are compiled on demand, that is, just before displayed for the first time. This is when it becomes necessary to have the assembly available. (There's an option to pre-compile the views together with the rest of the code, but this is another story.) On the other hand, if you set the verbosity to Diagnostic you get the following output:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.Web.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

As a result, all you need to do is either:

1. Add a reference to the assembly manually (locate it on disk, maybe GAC, and add it as a "direct" reference), or
2. Use NuGet package (if published in the gallery) to download it and reference the assembly contained within it.

More about NuGet gallery here. More about precompiling ASP.NET views here.

Obviously there's a lot of different causes and thus a lot of solutions for this problem. To throw mine into the mix, we upgraded an assembly (System.Net.Http) that was previously directly referenced in our Web project to a version managed by NuGet. This removed the direct reference within that project, but our Test project still contained the direct reference. Upgrading both projects to use the NuGet-managed assembly resolved the issue.

I have uninstalled Microsoft ASP.NET MVC nuget.org from manage NuGet Packagaes and again re-installed it. While re-installing it resolved all the conflicts related to razor version. Try it .

I had this warning after migrating to Package Reference. In diagnostic output there was information that library was referenced by the same library itself. It might be a bug of new Package Reference. The solution was to enable AutoGenerateBindingRedirects and delete custom binding redirect.