Warning: Found conflicts between different versions of the same dependent assembly

This warning means that two projects reference the same assembly (e.g. System.Windows.Forms) but the two projects require different versions. You have a few options:

Recompile all projects to use the same versions (e.g. move all to .Net 3.5). This is the preferred option because all code is running with the versions of dependencies they were compiled with. Add a binding redirect. This will suppress the warning. However, your .Net 2.0 projects will (at runtime) be bound to the .Net 3.5 versions of dependent assemblies such as System.Windows.Forms. You can quickly add a binding redirect by double-clicking on error in Visual Studio. Use CopyLocal=true. I'm not sure if this will suppress the warning. It will, like option 2 above, mean that all projects will use the .Net 3.5 version of System.Windows.Forms.

Here are a couple of ways to identify the offending reference(s):

You can use a utility such as the one found at https://gist.github.com/1553265

Another simple method is to set Build output verbosity (Tools, Options, Projects and Solutions, Build and Run, MSBuild project build output verbosity, Detailed) and after building, search the output window for the warning, and look at the text just above it. (Hat tip to pauloya who suggested this in the comments on this answer).

Basically this happens when the assemblies you're referencing have "Copy Local" set to "True", meaning that a copy of the DLL is placed in the bin folder along with your exe.

Since Visual Studio will copy all of the dependencies of a referenced assembly as well, it's possible to end up with two different builds of the same assembly being referred to. This is more likely to happen if your projects are in separate solutions, and can therefore be compiled separately.

The way I've gotten around it is to set Copy Local to False for references in assembly projects. Only do it for executables/web applications where you need the assembly for the finished product to run.

Hope that makes sense!

I wanted to post pauloya's solution they provided in the comments above. I believe it is the best solution for finding the offending references.

The simplest way to find what are the "offending reference(s)" is to set Build output verbosity (Tools, Options, Projects and Solutions, Build and Run, MSBuild project build output verbosity, Detailed) and after building, search the output window for the warning. See the text just above it.

For example, when you search the output panel for "conflict" you may find something like this:

3>  There was a conflict between "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
3>      "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it was primary and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was not.

As you can see, there is a conflict between EF versions 5 and 6.

On Visual Studio if you right click on the solution and Manage nuget packages theres a "Consolidate" tab which sets all the packages to the same version.

I had the same problem with one of my projects, however, none of the above helped to solve the warning. I checked the detailed build logfile, I used AsmSpy to verify that I used the correct versions for each project in the affected solution, I double checked the actual entries in each project file - nothing helped.

Eventually it turned out that the problem was a nested dependency of one of the references I had in one project. This reference (A) in turn required a different version of (B) which was referenced directly from all other projects in my solution. Updating the reference in the referenced project solved it.

Solution A
+--Project A
   +--Reference A (version 1.1.0.0)
   +--Reference B
+--Project B
   +--Reference A (version 1.1.0.0)
   +--Reference B
   +--Reference C
+--Project C
   +--Reference X (this indirectly references Reference A, but with e.g. version 1.1.1.0)

Solution B
+--Project A
   +--Reference A (version 1.1.1.0)

I hope the above shows what I mean, took my a couple of hours to find out, so hopefully someone else will benefit as well.

I just had this warning message and cleaned the solution and recompiled (Build -> Clean Solution) and it went away.

I had the same issue and I resolved by changing the following in web.config.

It happened to me because I am running the application using Newtonsoft.Json 4.0

From:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

To:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

I have another way to do this if you're using Nuget to manage your dependencies. I've discovered that sometimes VS and Nuget don't match up and Nuget is unable to recognize that your projects are out of sync. The packages.config will say one thing but the path shown in References - Properties will indicate something else.

If you're willing to update your dependencies, do the following:

From Solution Explorer, right click the Project and click 'Manage Nuget Packages' Select 'Installed packages' tab in left pane Record your installed packages You may want to copy your packages.config to your desktop first if you have a lot, so you can cross check it with Google to see what Nuget pkgs are installed Uninstall your packages. Its OK, we're going to add them right back. Immediately install the packages you need. What Nuget will do is not only get you the latest version, but will alter your references, and also add the binding redirects for you. Do this for all of your projects. At the solution level, do a Clean and Rebuild.

You may want to start with the lower projects and work your way to the higher level ones, and rebuild each project as you go along.

If you don't want to update your dependencies, then you can use the package manager console, and use the syntax Update-Package -ProjectName [yourProjectName] [packageName] -Version [versionNumber]

This actually depends on your external component. When you reference an external component in a .NET application it generates a GUID to identify that component. This error occurs when the external component referenced by one of your projects has the same name and but different version as another such component in another assembly.

This sometimes happens when you use "Browse" to find references and add the wrong version of the assembly, or you have a different version of the component in your code repository as the one you installed in the local machine.

Do try to find which projects have these conflicts, remove the components from the reference list, then add them again making sure that you're pointing to the same file.

I just spent sometime debugging the same issue. Note, that issue might not be between different projects, but actually between several references in one project that depend on different versions of the same dll/assembly. In my case, issue was reference FastMember.dll versions mismatch that comes from two different NuGet packages in a single project. When I was given a project, it would not compile because NuGet packages were missing and VS refused to restore missing packages. Through the NuGet menu, I manually update all the NuGets to the latest version, that is when the warning appeared.

In Visual Studio Tools > Options > Build and Run > MSBuld Project build output verbosity: (set to) Diagnostics. Look for the line(s) There was a conflict between in the Output window. Below is the part of output that I got:

1>  There was a conflict between "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null". (TaskId:19)
1>      "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" was chosen because it was primary and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" was not. (TaskId:19)
1>      References which depend on "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" [C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll]. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll". (TaskId:19)
1>              FastMember, Version=1.5.0.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)
1>      References which depend on "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" []. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll". (TaskId:19)
1>              ClosedXML, Version=0.94.2.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)

Notice, that Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll"

ClosedXML.dll comes from ClosedXML NuGet and it depends on FastMember.dll 1.3.0.0. On top of it, there is also FastMember Nuget in the project, and it has FastMember.dll 1.5.0.0. Mismatch !

I have uninstalled ClosedXML & FastMember NuGets, because I had binding redirect and installed just latest version of ClosedXML That fixed the issue !

Also had this problem - in my case it was caused by having the "Specific Version" property on a number of references set to true. Changing this to false on those references resolved the issue.

=> check there will be some instance of application installed partially.

=> first of all uninstall that instance from uninstall application.

=> then,clean,Rebuild,and try to deploy.

this solved my issue.hope it helps you too. Best Regards.

If using NuGet all I had to do was:

right click project and click Manage NuGet Packages.. click the cog in top right click General tab in NuGet Package Manager above Package Sources check "Skip Applying binding redirects" in Binding Redirects Clean and rebuild and the warning's gone

Easy peasy

This happened to me too. One dll was referenced twice: once directly (in references) and once indirectly (referenced by another referenced project). I removed direct reference, cleaned & rebuilt solution. Problem fixed.

Open "Solution Explorer". Click on "Show all files" Expand "References" You'll see one (or more) reference(s) with slightly different icon than the rest. Typically, it is with yellow box suggesting you to take a note of it. Just remove it. Add the reference back and compile your code. That's all.

In my case, there was a problem with MySQL reference. Somehow, I could list three versions of it under the list of all available references; for .net 2.0, .net 4.0 and .net 4.5. I followed process 1 through 6 above and it worked for me.

Another thing to consider and check is, make sure you don't have any service running that's using that bin folder. if their is stop the service and rebuild solution

There seems to be a problem on Mac Visual Studio when editing .resx files. I don't really know what happened, but I got this problem as soon as I edited some .resx files on my Mac. I opened the project on Windows, opened the files and they were as if they haven't been edited. So I edited them, saved, and everything started working again on Mac too.

I had such issue when my project had reference to NETStandardLibrary and one of referenced assemblies was published for netcore. Just published it as netstandard and problem was gone

Here's the solution, .NET Core 3.0 style: https://github.com/HTD/ref-check

When you find what conflicts, maybe you would be able to resolve the conflicts. If the conflicting references are from other packages, you either out of luck, or you need to use sources instead.

In my case, the packages conflicting are often of my own, so I can fix dependency problems and republish them.

I had the same problem. In the project's 'obj' folder I renamed the folder 'Debug' to 'Debug_OLD' and rebuilt. A new 'Debug' folder was built automatically, and the problem went away.