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

Question

I am currently developing a .NET application, which consists of 20 projects. Some of those projects are compiled using .NET 3.5, some others are still .NET 2.0 projects (so far no problem).

The problem is that if I include an external component I always get the following warning:

Found conflicts between different versions of the same dependent assembly.

What exactly does this warning mean and is there maybe a possibility to exclude this warning (like using #pragma disable in the source code files)?

score 441 · Accepted Answer · edited Jan 06 '18 at 01:28

441

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

edited Jan 06 '18 at 01:28

Rick Riensche

1,050
1
12
25

answered Jan 26 '10 at 05:54

Brian Low

11,605
4
58
63

9

Just for one quick way to find it without the utility--if you do add the binding redirect (as option 2), it will show there the reference(s) involved--if desired, you can then use one of the other methods to handle it, and delete the binding redirect(s) from your config file. – Brisbe Jun 07 '11 at 23:09
239

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. – pauloya Oct 12 '11 at 15:10
1

Alternatively, allow VS to create the binding redirect and then use a diff viewer to see what it's added. This will tell you what the offending reference is. – David Apr 20 '12 at 16:06
10

Binding redirect by double clicking warning (step 2) don't remove my warning. I see app.config added with the assembly I suspect is the cause, but the warning is still there after a clean/rebuild. Also tried step 3 in addition, no luck. Any ideas? – angularsen May 20 '12 at 09:25
1

much easier approach from my point of view would be to set MSBuild output to Verbose - you will see conflicting assemblies right away: http://stackoverflow.com/questions/1871073/resolving-msb3247-found-conflicts-between-different-versions-of-the-same-depen – avs099 May 24 '13 at 20:22
13

What if they're not references from your own projects? For example, I referenced a project, which has dependency on Newtonsoft.Json, Version=6.0.0.0, and I referenced another project, which has dependency on Newtonsoft.Json, Version=4.5.0.0 – Edward Ned Harvey Oct 10 '14 at 19:39
2

This question seems to reflect a base problem: there is no effective way (at least I'm not aware) to manage dependencies in .NET yet. NuGet and Visua Studio continue biting each other... What's wrong with different library modules depend on different versions of the same third party lib? If we redirect the library to always use the newer version, something might break.. – Hoàng Long Dec 17 '15 at 03:48
@EdwardNedHarvey see this SO post http://stackoverflow.com/questions/24772053/found-conflicts-between-different-versions-of-the-same-dependent-assembly-that-c – david.barkhuizen Jan 15 '16 at 10:45
Thanks a bunch. In my case there were no conflicting assemblies. All it was, was a Test class that did not have the public modifier. The utility that you referenced identified it. Thanks again. – FernandoZ Nov 09 '17 at 05:30
3

@brian-low, may I suggest adding the Build output verbosity setting (as suggested in comment by @pauloya) as an option in your answer alongside the linked utility? (Disclaimer, I actually tried to edit the answer to do just that but it was rejected upon review :)) – Rick Riensche Jan 05 '18 at 21:25

score 46 · Answer 2 · answered Aug 20 '08 at 12:08

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!

user1477388 · Answer 3 · 2015-12-22T13:18:56.273

35

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.

edited Dec 22 '15 at 13:18

answered Nov 10 '15 at 15:18

user1477388

20,790
32
144
264

5

But now that I have this information, how do I remove the error? I can see what the conflict is, but I can't find where the project is referencing the conflicting version – Bassie Nov 10 '16 at 17:19
Hi @Bassie, the first thing to do would be to check your nuget package file and determine if you need to update all files to the same version of the package. You can do this by running a command similar to `update-package [your package name] -version 6.0.0 -reinstall` as per my answer here http://stackoverflow.com/questions/22685530/could-not-load-file-or-assembly-newtonsoft-json-or-one-of-its-dependencies-ma/26891914#26891914 – user1477388 Nov 10 '16 at 17:59
@Bassie, you can do what the warning suggests, and add the binding redirect to the app.config file! (if updating isn't an option, that is.) – BrainSlugs83 Jun 30 '17 at 20:53
@Bassie see my answer, where I show you have you how to get different assemblies/.dlls that are causing mismatch issues. – newprint Jun 12 '19 at 21:04

score 29 · Answer 4 · answered Sep 30 '16 at 17:48

29

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.

answered Sep 30 '16 at 17:48

Tiago Gouvêa

15,036
4
75
81

score 23 · Answer 5 · answered Nov 09 '12 at 16:44

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.

Same problem here. However, I have no chance to update the reference to a newer version. I tried using an App.config: while it works for the application, Visual Studio 2010 seems to ignore it during build. — Thomas Weller, Dec 19 '12 at 09:56
wow, I've had these problems for two months and couldn't pinpoint and solve it. For some reason it would crash only during debugging and in some cases, it would manualy replace the bothersome .dll with the real one in the bin folder when that would happen. Debugging was a real pain. When I read your answer I realised this was exactly what was happening to me and I fixed it in like 5 minutes :) — Dennis Puzak, Jan 13 '14 at 17:39

score 9 · Answer 6 · answered Jan 16 '12 at 22:50

9

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

answered Jan 16 '12 at 22:50

MoMo

8,149
3
35
31

11

Only until you rebuild the solution though – Luke Aug 24 '14 at 14:22
This saves me! I've been trying other solution since yesterday but this one solved my problem. Including the comment above this^. Thanks! – MuntingInsekto Feb 12 '16 at 04:38

score 6 · Answer 7 · edited May 14 '15 at 06:52

6

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>

edited May 14 '15 at 06:52

Dave New

38,496
59
215
394

answered Jul 13 '14 at 15:39

Phil50

71
1
2

This was the solution for me. I had a binding redirect to the higher version, and it only worked once I moved to the lower version. – mrwaim Oct 26 '14 at 19:53
1

why? So strange for me. I don't use EF, but I thought we always want to move to the last version? – Hoàng Long Dec 17 '15 at 03:31
1

@HoàngLong because the version you're referencing is the older version, but the version you're including is the newer one. – BrainSlugs83 Oct 06 '16 at 22:27

score 3 · Answer 8 · answered Apr 09 '14 at 00:48

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]

score 2 · Answer 9 · answered Aug 20 '08 at 12:11

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.

newprint · Answer 10 · 2019-06-12T21:07:03.363

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 !

score 1 · Answer 11 · answered Nov 20 '14 at 02:47

1

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.

answered Nov 20 '14 at 02:47

Tristan Lewis

36
2

score 1 · Answer 12 · answered Apr 18 '17 at 09:06

1

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

answered Apr 18 '17 at 09:06

Neelam Prajapati

3,764
3
28
62

score 1 · Answer 13 · answered May 31 '19 at 22:17

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

score 0 · Answer 14 · answered Feb 12 '14 at 14:01

0

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.

answered Feb 12 '14 at 14:01

Igor Gorjanc

535
4
17

score 0 · Answer 15 · answered Jun 15 '14 at 05:25

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.

score 0 · Answer 16 · answered Oct 09 '17 at 09:14

0

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

answered Oct 09 '17 at 09:14

Telwa Gangnam

31
7

score 0 · Answer 17 · answered Mar 12 '18 at 23:55

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.

score 0 · Answer 18 · answered Apr 05 '19 at 09:36

0

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

answered Apr 05 '19 at 09:36

Jacek Plesnar

479
3
6

score 0 · Answer 19 · answered Sep 26 '19 at 20:58

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.

score 0 · Answer 20 · answered Oct 03 '21 at 14:59

0

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.

answered Oct 03 '21 at 14:59

Tim Makins

394
4
12

score 0 · Answer 21 · answered Oct 25 '22 at 15:38

0

After some hours of trying to analyze the detailed build log, I discovered that several of the projects in my solution were targeting different .Net versions. I changed them all to .Net 4.7.2 and rebuilt the solution and the error was resolved.

answered Oct 25 '22 at 15:38

Kluge

3,567
3
24
21

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

21 Answers21

Linked