ChatGPT解决这个技术问题 Extra ChatGPT

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?

I submitted to MS Connect suggestion to include DLL name in the message connect.microsoft.com/VisualStudio/feedback/details/2619450
My case was because of <PrivateAssets> in project A. It bumped up the version of one of the other dependencies (lets call it package X) to a higher version. Solution also has project B which has projekt A as a reference. It sees package X "low version" (and picks that as the "primary" version) because the higher version requested by the private asset is... well private - not visible. Now come time to build: PackageX.dll "low version" is copied to output, assembly projectA.dll is copied to outp... no wait! projectA.dll requires projekt X "higher version" ->unsolvable DLL-HELL -> build fail.

C
Community

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 :)


Thanks - been using Visual Studio for many years and never had a problem that required digging this deep in the build log. Different problem but realizing that the information that I was looking was being emitted somewhere solved my problem.
Log level detailed seems to work inside VS (so no diagnostic required). Wouldn't be the first time though that MSBuild behaves differently inside VS....
To change the log verbosity from the menu Tools->Options, then find Project and Solutions->Build and Run
In my case, I had three conflicts and one of them was responsible for the other two. I copied my "detailed" build log to Notepad, searched for "conflict", updated the NuGet package for the reference I recognized, and the problem was solved.
This was my exact issue, down to it being because of Newtonsoft.Json. But why are there 2 versions, and do I need to worry about this error? I think this library was added with a NuGet package.
R
Ruben Bartelink

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]

I ended up piping that command to a log file, so I could look over it easier: msbuild "Foo.sln" /t:Rebuild /v:d > build.log
Best way to get to the terminal for this: stackoverflow.com/a/22702405/268066
@CrazyPyro msbuild has a "built in" pipe -- /l:FileLogger,Microsoft.Build.Engine;logfile=build.log -- note the switches for loggers explanation here
Where is the "build log" located? How do I find it?
This answer shows how to get more details from msbuild, which is what a mono user cares about. All the other answers assume you are using VS and running in a Windows environment.
A
Alexander Christov

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

https://i.stack.imgur.com/61xPl.png

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:

Add a reference to the assembly manually (locate it on disk, maybe GAC, and add it as a "direct" reference), or 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.


In VS 2017, when I set the "MSBuild project build output verbosity" (not the log file) to Detailed (not Diagnostic), I got the "Could not locate the assembly" error in my Output window.
@ALEXintlsos: apparently this functionality has changed; still you got the error wherever it is - follow the instruction to get rid of it.
R
Rosdi Kasim

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

Go to Tools->Options menu in VS Open Projects and Solutions->Build and Run 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.


S
Shaswat Rungta

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.


this didn't solve for me. I had to uninstall Newtonsoft.JSON and reinstall through NuGet. This updated dependencies on the other packages.
This also happened to me when using tools like Resharper, which auto add missing references of DLL. "Always add using nuget" could be a good suggestion here.
It doesn't work for me because to uninstall a package it attempts a build which cannot happen because there is a conflict of packages. So I am even unable to get to reinstalling the package :(
C
Community

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.


This, with a combination of restarting Visual Studio when it refused to reinstall a package properly, solved the issue for me.
Simplest way to check: Right click on solution -> Manage NuGet packages for solution -> Under Consolidate you can see if there are different versions of the same package was installed
R
RandomHandle

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.


N
Nathan Tuggy

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


This did not work for me; the situation was the same after running the command.
@Zimano This did work for me but only after exiting Visual Studio and restarting! Then rebuilding the project solved the issue.
C
Carolina

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


j
joelmdev

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.


N
Naumaan Shaikh

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


P
Prince Owen

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.


A
Auri Rahimzadeh

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:


T
Tom Makin

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.


A
Andrew

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.


u
user8128167

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>

j
jitendra r

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 .


P
Pantelitsa Mavrovounioti

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.


c
car1bo

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.


r
raV720

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.


J
Jonathan Applebaum

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.


T
Tayron Ovares

I have installed Newtonsoft.Json v10.0.0.3 and Newtonsoft.Json v11.X.X.X in diferente projects from nuget.org from manage NuGet Packagaes and again re-installed it (same version) . While re-installing it resolved all the conflicts related to razor version. Work for me!