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)?
This question is tagged with
~ Asked on 2008-08-20 12:00:59
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.
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):
~ Answered on 2010-01-26 05:54:29
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!
~ Answered on 2008-08-20 12:08:05
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=126.96.36.199, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "EntityFramework, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b77a5c561934e089". 3> "EntityFramework, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it was primary and "EntityFramework, Version=220.127.116.11, Culture=neutral, PublicKeyToken=b77a5c561934e089" was not.
As you can see, there is a conflict between EF versions 5 and 6.
~ Answered on 2015-11-10 15:18:50
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 on 2016-09-30 17:48:29
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 18.104.22.168) +--Reference B +--Project B +--Reference A (version 22.214.171.124) +--Reference B +--Reference C +--Project C +--Reference X (this indirectly references Reference A, but with e.g. version 126.96.36.199) Solution B +--Project A +--Reference A (version 188.8.131.52)
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.
~ Answered on 2012-11-09 16:44:13
I just had this warning message and cleaned the solution and recompiled (Build -> Clean Solution) and it went away.
~ Answered on 2012-01-16 22:50:11
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
<dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-184.108.40.206" newVersion="220.127.116.11" /> </dependentAssembly>
<dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-18.104.22.168" newVersion="22.214.171.124" /> </dependentAssembly>
~ Answered on 2014-07-13 15:39:50
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]
~ Answered on 2014-04-09 00:48:34
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.
~ Answered on 2008-08-20 12:11:30
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=126.96.36.199, Culture=neutral, PublicKeyToken=null" and "FastMember, Version=188.8.131.52, Culture=neutral, PublicKeyToken=null". (TaskId:19) 1> "FastMember, Version=184.108.40.206, Culture=neutral, PublicKeyToken=null" was chosen because it was primary and "FastMember, Version=220.127.116.11, Culture=neutral, PublicKeyToken=null" was not. (TaskId:19) 1> References which depend on "FastMember, Version=18.104.22.168, 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=22.214.171.124, Culture=neutral, processorArchitecture=MSIL (TaskId:19) 1> References which depend on "FastMember, Version=126.96.36.199, 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)
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 188.8.131.52. On top of it, there is also
FastMember Nuget in the project, and it has
FastMember.dll 184.108.40.206. Mismatch !
I have uninstalled
FastMember NuGets, because I had binding redirect and installed just latest version of
ClosedXML That fixed the issue !
~ Answered on 2019-06-12 21:01:28
=> 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 on 2017-04-18 09:06:27
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 on 2014-11-20 02:47:05
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
~ Answered on 2019-05-31 22:17:45
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.
~ Answered on 2014-06-15 05:25:44
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.
~ Answered on 2018-03-12 23:55:03
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 on 2014-02-12 14:01:36
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 on 2019-04-05 09:36:21
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 on 2017-10-09 09:14:19
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.
~ Answered on 2019-09-26 20:58:52