We Keep Coding

Unable to load System.Threading.Tasks.Extensions

I have a web project build on .net framework 4.5.1. We are trying to added PostgreSQL support for the project. Using Nuget, I have installed 4.0.4 npgsql to the project. Under references, I see the following being added to the project.
Npgsql - 4.0.4.0 - Runtime version v4.0.30319
System.Threading.Tasks.Extensions - 4.2.0.0 - Runtime version v4.0.30319
When I tried run the project and connect and get the data from the database, I am getting the following error saying FileNotFoundException:
System.TypeInitializationException
HResult=0x80131534
Message=The type initializer for 'com.rsol.RConfig' threw an exception.
Source=RConfig
StackTrace:
at com.rsol.RConfig.getInstance() in C:\Workspaces\PS\RConfig\RConfig.cs:line 1113
at RAdmin.Global.Application_Start(Object sender, EventArgs e) in C:\Workspaces\PS\RAdmin\Global.asax.cs:line 528
Inner Exception 1:
TypeInitializationException: The type initializer for 'com.rsol.Db.DbMgr' threw an exception.
Inner Exception 2:
FileNotFoundException: Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
Inner Exception 3:
FileNotFoundException: Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
System.Threading.Tasks.Extensions which is installed using Nuget is not getting loaded to the project. When I checked the properties of System.Threading.Tasks.Extensions reference, the dll file exists in the location. I have also tried installing System.Threading.Tasks.Extensions.dll file to assembly using gacutil. I am still getting the same error.
Please let me know if you need any additional information.
Any help is really appreciated.

In my case, I got the issue after upgrading to version 4.5.4 and tried #user2713341 answer. It didn't work but put me in the right direction.
My project had no bindings for this library, so I added the binding and it worked
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>
and it worked.
Note that it should be 4.2.0.1 even though the version is 4.5.4.

Update Nuget Package
https://www.nuget.org/packages/System.Threading.Tasks.Extensions/
will solve your problem

Update Nuget Package is not working for me.
What works?
In app.config need to change
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
To
<bindingRedirect oldVersion="0.0.0.0-4.5.4" newVersion="4.5.4" />
for current version 4.7.2 should work.
Microsoft like ;)

The response from #Keyjote was at the root of the solution for me, but rather than cherry-picking the assemblies, I was able to just reinstall. This seemed to automatically repair the app.config file.
Tools -> Nuget Packet Manager -> Packet Manager Console
Update-Package -reinstall -Project <your project name>
This way you don't need to mess with the syntax or have to figure out the PublicKeyToken values.
If you want to do it for the whole solution, you can omit the -Project <> parameter.

I got the error in a different context when trying to migrate using Entity Framework Core (EFC) Version 3.1.8 using the Package Manager Console. The project built successfully.
Trying the binding redirects as suggested in this thread and (re)installing different versions of System.Threading.Tasks.Extensions as well as EFC (as suggested also elsewhere) did not work for me.
I managed to solve the problem by
deleting the packages/ directory in my project's root directory
using manual NuGet Package Restore (link to Microsoft Docs) via Visual Studio

problem lies in *.csproj file. having wrong reference for System.Threading.Tasks.Extensions.4.5.4 because this dll not loading.
after referring correct framework version folder from lib its start working
old Reference:
<Reference Include="System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
<HintPath>..\packages\System.Threading.Tasks.Extensions.4.5.2\lib\netstandard2.0\System.Threading.Tasks.Extensions.dll</HintPath>
</Reference>
corrected one:
<Reference Include="System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
<HintPath>..\packages\System.Threading.Tasks.Extensions.4.5.4\lib\net472\System.Threading.Tasks.Extensions.dll</HintPath>
</Reference>
please clean the nuget cache first, then run test case it will work

I have been struggling a lot with bindingRedirect.
I finally found a real gotcha that solved my problems.
I have a WCF server project in .net 4.8, depending on projects in .net standard 2.0.
I was updating Nuget packages in the referred projects.
I got al sorts of problems, I won't try to mention them here.
I had bindingRedirects in web.config. I had to rediscover that those were unnecessary, and maybe even conflicting, because of automatic generation of those into the dll.config. There are various aspects to make that work, see elsewhere.
But the real gotcha for me was that for IIS, I had to LINK web.config to the dll.config. The latter being the complete config-file, with all the bindingRedirects, which turned out to be working after all.

Try to download the package and add reference to your project explicitly . should work , I just resolved it .

I got a similar error message - but for a different reason. In packages.config set by NUGET manager There was a ref for the new version - but in project reference there was a ref for an old version. The solution - delete the ref in project reference

System.IO.FileNotFoundException: 'Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0,

This is the error that I get:
System.IO.FileNotFoundException: 'Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The system cannot find the file specified.'
This is what I have in cs project:
<Reference Include="Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<HintPath>..\packages\Newtonsoft.Json.12.0.3\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>
The path seems to be correct.
I tried to find different solutions such as reinstalling the package to earlier version and modifying the app.config to this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1"/>
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-12.0.0.0" newVersion="12.0.3.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Nothing has worked.

In my case, I have installed the V 12.0.0.3 by the Nuget package and I got the same error. According to my own experience . some of NewtonSoft versions are getting mad with some version of the Visual studio.
if you just need simple deserialize and serialize functionality, your problem will be solved if you reinstall the Newtonsoft current package from your solution and install the version 6.0.3
This version is so compatible with visual studio different versions.

Even though I had installed the Newtonsoft via "Manage NuGet Packages for Solution" I was still receiving this error. My fix was simple – I had to also add the "Newtonsoft.Json.dll" as a reference.
1. Right-click "References" > Add > Reference > Browse > C:\Users\<username>\.nuget\packages\newtonsoft.json\12.0.3\lib\portable-net45+win8+wp8+wpa81\Newtonsoft.Json.dll > Click the "Add" button > Click "OK"
2. I did a Build/Clean Solution (that step may not have been necessary)
3. Build/Build Solution
Reran and the exception was gone.

This worked for me :
My issue : Recently updated newtonsoft to 13.0.0.0 and now VS is complaining about missing 9.0.0.0
Check the version of your Newtonsoft.JSON in References
Open Web.Config and change the bindingRedirect to the version in your reference

In your error it is stated that library version "12.0.0.0" was not found. In your config reference the version listed is "12.0.3"
The version mismatch could be the cause here.
When i encounter this issue it is usually after checking out code from source control and for some reason the references are missing. In this case it helped me to uninstall the nugets, check in, reinstall them and build (and check in again). Maybe this will work for you.

I had this exact same issue, i was working on a Web API and a self written DLL i wanted to debug.
Working on my DLL in the other project gave me this error.
But i followed these steps to finally resolve my issue:
Reinstall Newtonsoft.Json
Restart Visual Studio
Clean solution (i believe this is the real solution)
Build/Rebuild solution

I suspect that when your project runs it isn't reading the .config that you expect because it is running from a different process. Try renaming your .config to match the calling process.
It might help to give more details about the type of VS project that you have.

This feels like one of those deja-vu issues for me - this particular time this exception was being thrown when my C# EXE file trying to call a web service. After trying to uninstall/reinstall/clean/rebuild/restart VStudio a dozen or so times I finally found a solution which was to just copy the files "Newtonsoft.Json.dll" and "Newtonsoft.Json.xml" to the output directory (alongside the EXE) - after doing this the error FINALLY went away.
FWIW I realize this is very likely a hacky/ugly solution and not really solving the core issue - I'm just happy I can move on now.

Function failed when called from other project due to assembly file c# [duplicate]

I am trying to run some unit tests in a C# Windows Forms application (Visual Studio 2005), and I get the following error:
System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.200, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)**
at x.Foo.FooGO()
at x.Foo.Foo2(String groupName_) in Foo.cs:line 123
at x.Foo.UnitTests.FooTests.TestFoo() in FooTests.cs:line 98**
System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.203, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I look in my references, and I only have a reference to Utility version 1.2.0.203 (the other one is old).
Any suggestions on how I figure out what is trying to reference this old version of this DLL file?
Besides, I don't think I even have this old assembly on my hard drive.
Is there any tool to search for this old versioned assembly?

The .NET Assembly loader:
is unable to find 1.2.0.203
but did find a 1.2.0.200
This assembly does not match what was requested and therefore you get this error.
In simple words, it can't find the assembly that was referenced. Make sure it can find the right assembly by putting it in the GAC or in the application path.
run below command to add the assembly dll file to GAC:
gacutil /i "path/to/my.dll"
Also see https://learn.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference.

You can do a couple of things to troubleshoot this issue. First, use Windows file search to search your hard drive for your assembly (.dll). Once you have a list of results, do View->Choose Details... and then check "File Version". This will display the version number in the list of results, so you can see where the old version might be coming from.
Also, like Lars said, check your GAC to see what version is listed there. This Microsoft article states that assemblies found in the GAC are not copied locally during a build, so you might need to remove the old version before doing a rebuild all. (See my answer to this question for notes on creating a batch file to do this for you)
If you still can't figure out where the old version is coming from, you can use the fuslogvw.exe application that ships with Visual Studio to get more information about the binding failures. Microsoft has information about this tool here. Note that you'll have to enable logging by setting the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog registry key to 1.

I just ran into this problem myself, and I found that the issue was something different than what the others have run into.
I had two DLLs that my main project was referencing: CompanyClasses.dll and CompanyControls.dll. I was getting a run-time error saying:
Could not load file or assembly
'CompanyClasses, Version=1.4.1.0,
Culture=neutral,
PublicKeyToken=045746ba8544160c' or
one of its dependencies. The located
assembly's manifest definition does
not match the assembly reference
Trouble was, I didn't have any CompanyClasses.dll files on my system with a version number of 1.4.1. None in the GAC, none in the app folders...none anywhere. I searched my entire hard drive. All the CompanyClasses.dll files I had were 1.4.2.
The real problem, I found, was that CompanyControls.dll referenced version 1.4.1 of CompanyClasses.dll. I just recompiled CompanyControls.dll (after having it reference CompanyClasses.dll 1.4.2) and this error went away for me.

The following redirects any assembly version to version 3.1.0.0. We have a script that will always update this reference in the App.config so we never have to deal with this issue again.
Through reflection you can get the assembly publicKeyToken and generate this block from the .dll file itself.
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
</dependentAssembly>
</assemblyBinding>
Note that without an XML namespace attribute (xmlns) this will not work.

If you are using Visual Studio, try "clean solution" and then rebuild your project.

I am going to blow everyone's mind right now . . .
Delete all the <assemblyBinding> references from your .config file, and then run this command from the NuGet Package Manager console:
Get-Project -All | Add-BindingRedirect

The other answers wouldn't work for me. If you don't care about the version and you just want your app to run then right click on the reference and set 'specific version' to false...This worked for me.

In my case, this error occurred while running an ASP.NET application.
The solution was to:
Delete the obj and bin folders in the project folder
Clean didn't work, rebuild didn't work, all references were fine, but it wasn't writing one of the libraries. After deleting those directories, everything worked perfectly.

I added a NuGet package, only to realize a black-box portion of my application was referencing an older version of the library.
I removed the package and referenced the older version's static DLL file, but the web.config file was never updated from:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
to what it should have reverted to when I uninstalled the package:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

I just ran across this issue and the problem was I had an old copy of the .dll in my application debug directory. You might want to also check there (instead of the GAC) to see if you see it.

In my case it was an old version of the DLL in C:\WINDOWS\Microsoft.NET\Framework\~\Temporary ASP.NET Files\ directory. You can either delete or replace the old version, or you can remove and add back the reference to the DLL in your project. Basically, either way will create a new pointer to the temporary ASP.NET Files.

Is possible you have a wrong nugget versions in assemblyBinding try:
Remove all assembly binding content in web.config / app.config:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.Logging.Abstractions" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.3.0" newVersion="3.1.3.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.DependencyInjection" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.3.0" newVersion="3.1.3.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0" />
</dependentAssembly>
</assemblyBinding>
Type in Package Manager Console: Add-BindingRedirect
All necessary binding redirects are generated
Run your application and see if it works properly. If not, add any missing binding redirects that the package console missed.

For us, the problem was caused by something else. The license file for the DevExpress components included two lines, one for an old version of the components that was not installed on this particular computer. Removing the older version from the license file solved the issue.
The annoying part is that the error message gave no indication to what reference was causing the problems.

I would like to just add that I was creating a basic ASP.NET MVC 4 project and added DotNetOpenAuth.AspNet via NuGet. This resulted in the same error after I referenced a mismatching DLL file for Microsoft.Web.WebPages.OAuth.
To fix it I did a Update-Package and cleaned the solution for a full rebuild.
That worked for me and is kind of a lazy way, but time is money:-P

This exact same error is thrown if you try to late bind using reflection, if the assembly you are binding to gets strong-named or has its public-key token changed. The error is the same even though there is not actually any assembly found with the specified public key token.
You need to add the correct public key token (you can get it using sn -T on the dll) to resolve the error. Hope this helps.

I got this error while building on Team Foundation Server's build-service. It turned out I had multiple projects in my solution using different versions of the same library added with NuGet. I removed all old versions with NuGet and added the new one as reference for all.
Team Foundation Server puts all DLL files in one directory, and there can only be one DLL file of a certain name at a time of course.

My issue was copying source code to a new machine without pulling over any of the referenced assemblies.
Nothing that I did fixed the error, so in haste, I deleted the BIN directory altogether. Rebuilt my source code, and it worked from then on out.

Mine was a very similar situation to the post by Nathan Bedford but with a slight twist. My project too referenced the changed dll in two ways. 1) Directly and 2) Indirectly by referencing a component (class library) that itself had a reference to the changed dll. Now my Visual studio project for the component(2) referenced the correct version of the changed dll. However the version number of the compnent itself was NOT changed. And as a result the install of the new version of the project failed to replace that component on the client machine.
End result: Direct reference (1) and Indirect reference(2) were pointing to different versions of the changed dll at the client machine. On my dev machine it worked fine.
Resolution: Remove application; Delete all the DLLS from application folder; Re-install.Simple as that in my case.

After trying many of the above solutions with no fix, it came down to making sure 'Auto-generate binding redirects' was turned on within your application in Visual Studio.
More information on enabling automatic binding redirection can be found here: https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection

I'll let someone benefit from my shear stupidity. I have some dependencies to a completely separate application (let's call this App1). The dll's from that App1 are pulled into my new application (App2). Any time I do updates in APP1, I have to create new dll's and copy them into App2. Well. . .I got tired of copying and pasting between 2 different App1 versions, so I simply added a 'NEW_' prefix to the dll's.
Well. . . I'm guessing that the build process scans the /bin folder and when it matches something up incorrectly, it barfs with the same error message as noted above. I deleted my "new_" versions and it built just dandy.

My app.config contains a
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>
for npgsql. Somehow on the user's machine, my app.exe.config went missing. I am not sure if it was a silly user, installer glitch, or wacked out anti-virus yet. Replacing the file solved the issue.

I just found another reason why to get this error. I cleaned my GAC from all versions of a specific library and built my project with reference to specific version deployed together with the executable. When I run the project I got this exception searching for a newer version of the library.
The reason was publisher policy. When I uninstalled library's versions from GAC I forgot to uninstall publisher policy assemblies as well so instead of using my locally deployed assembly the assembly loader found publisher policy in GAC which told it to search for a newer version.

To me the code coverage configuration in the "Local.testtesttings" file "caused" the problem. I forgot to update the files that were referenced there.

Just deleting contents of your project's bin folder and rebuild the solution solved my problem.

I faced the same problem while running my unit testcases.
The error clearly states the problem is: when we try to load assembly, the .NET assembly loader tries to load its referred assemblies based on its manifest data (referred assembly name, public key token, version).
To check manifest data:
Open the Visual Studio command prompt,
Type 'ildasm' and drag the required assembly to the ILDASM window and open MANIFEST view. Sometimes MANIFEST contains one assembly with two versions old version as well as new version(like Utility, Version=1.2.0.200 and Utility, Version=1.2.0.203). In reality, the referred assembly is Utility, Version=1.2.0.203(new version), but since the manifest contains even Utility, Version=1.2.0.200(old version), .NET assembly loader tries to find out this versioned DLL file, fails to find and so throws exception.
To solve this, just drag each of the project dependent assemblies to the ILDASM window separately and check which dependent assembly holds the manifest data with the old assembly version. Just rebuild this dependent assembly and refer it back to your project.

A general answer to this kind of issue is to use binding redirects as in other answers. However, that's only part of the problem - you need to know the correct version of the assembly file that you're using. Windows properties is not always accurate and nuget is also not always accurate.
The only way to get correct version info is to analyse the file itself. One useful tool is dotPeek. The assembly name listed in dotPeek is always accurate in my experience.
So for example, the correct binding for this file is the following:
<dependentAssembly>
<assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0"/>
</dependentAssembly>
Windows explorer says the file is 4.6.26515.06, nuget says its a 5.0.0.0 file. dotPeek says it is 4.2.1.0 and that is the version that works correctly in our software. Also note that the public key and culture are important and dotPeek also show this information.

Here's my method of fixing this issue.
From the exception message, get the name of the "problem" library and the "expected" version number.
Find all copies of that .dll in your solution, right-click on them, and check which version of the .dll it is.
Okay, so in this example, my .dll is definitely 2.0.5022.0 (so the Exception version number is wrong).
Search for the version number which was shown in the Exception message in all of the .csproj files in your solution. Replace this version number with the actual number from the dll.
So, in this example, I would replace this...
<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
... with this...
<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
Job done !

The question has already an answer, but if the problem has occurred by NuGet package in different versions in the same solution, you can try the following.
Open NuGet Package Manager, as you see my service project version is different than others.
Then update projects that contain an old version of your package.

clean and rebuild the solution might not replace all the dll's from the output directory.
what i'll suggest is try renaming the folder from "bin" to "oldbin" or "obj" to "oldobj"
and then try build your silution again.
incase if you are using any third party dll's those you will need to copy into newly created "bin" or "obj" folder after successful build.
hope this will work for you.

No solution worked for me. I tried clean project solution, remove bin, update package, downgrade package and so on... After two hours I loaded default App.config from project with assemblies and there I changed wrong reference version from:
<dependentAssembly>
<assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
to:
<dependentAssembly>
<assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
After this I cleaned project, build it again and it worked. No warning no problem.

System.IO.FileLoadException: 'Could not load file or assembly 'Serilog' [duplicate]

I am trying to run some unit tests in a C# Windows Forms application (Visual Studio 2005), and I get the following error:
System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.200, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)**
at x.Foo.FooGO()
at x.Foo.Foo2(String groupName_) in Foo.cs:line 123
at x.Foo.UnitTests.FooTests.TestFoo() in FooTests.cs:line 98**
System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.203, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I look in my references, and I only have a reference to Utility version 1.2.0.203 (the other one is old).
Any suggestions on how I figure out what is trying to reference this old version of this DLL file?
Besides, I don't think I even have this old assembly on my hard drive.
Is there any tool to search for this old versioned assembly?

The .NET Assembly loader:
is unable to find 1.2.0.203
but did find a 1.2.0.200
This assembly does not match what was requested and therefore you get this error.
In simple words, it can't find the assembly that was referenced. Make sure it can find the right assembly by putting it in the GAC or in the application path.
run below command to add the assembly dll file to GAC:
gacutil /i "path/to/my.dll"
Also see https://learn.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference.

You can do a couple of things to troubleshoot this issue. First, use Windows file search to search your hard drive for your assembly (.dll). Once you have a list of results, do View->Choose Details... and then check "File Version". This will display the version number in the list of results, so you can see where the old version might be coming from.
Also, like Lars said, check your GAC to see what version is listed there. This Microsoft article states that assemblies found in the GAC are not copied locally during a build, so you might need to remove the old version before doing a rebuild all. (See my answer to this question for notes on creating a batch file to do this for you)
If you still can't figure out where the old version is coming from, you can use the fuslogvw.exe application that ships with Visual Studio to get more information about the binding failures. Microsoft has information about this tool here. Note that you'll have to enable logging by setting the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog registry key to 1.

I just ran into this problem myself, and I found that the issue was something different than what the others have run into.
I had two DLLs that my main project was referencing: CompanyClasses.dll and CompanyControls.dll. I was getting a run-time error saying:
Could not load file or assembly
'CompanyClasses, Version=1.4.1.0,
Culture=neutral,
PublicKeyToken=045746ba8544160c' or
one of its dependencies. The located
assembly's manifest definition does
not match the assembly reference
Trouble was, I didn't have any CompanyClasses.dll files on my system with a version number of 1.4.1. None in the GAC, none in the app folders...none anywhere. I searched my entire hard drive. All the CompanyClasses.dll files I had were 1.4.2.
The real problem, I found, was that CompanyControls.dll referenced version 1.4.1 of CompanyClasses.dll. I just recompiled CompanyControls.dll (after having it reference CompanyClasses.dll 1.4.2) and this error went away for me.

The following redirects any assembly version to version 3.1.0.0. We have a script that will always update this reference in the App.config so we never have to deal with this issue again.
Through reflection you can get the assembly publicKeyToken and generate this block from the .dll file itself.
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
</dependentAssembly>
</assemblyBinding>
Note that without an XML namespace attribute (xmlns) this will not work.

If you are using Visual Studio, try "clean solution" and then rebuild your project.

I am going to blow everyone's mind right now . . .
Delete all the <assemblyBinding> references from your .config file, and then run this command from the NuGet Package Manager console:
Get-Project -All | Add-BindingRedirect

The other answers wouldn't work for me. If you don't care about the version and you just want your app to run then right click on the reference and set 'specific version' to false...This worked for me.

In my case, this error occurred while running an ASP.NET application.
The solution was to:
Delete the obj and bin folders in the project folder
Clean didn't work, rebuild didn't work, all references were fine, but it wasn't writing one of the libraries. After deleting those directories, everything worked perfectly.

I added a NuGet package, only to realize a black-box portion of my application was referencing an older version of the library.
I removed the package and referenced the older version's static DLL file, but the web.config file was never updated from:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
to what it should have reverted to when I uninstalled the package:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

I just ran across this issue and the problem was I had an old copy of the .dll in my application debug directory. You might want to also check there (instead of the GAC) to see if you see it.

In my case it was an old version of the DLL in C:\WINDOWS\Microsoft.NET\Framework\~\Temporary ASP.NET Files\ directory. You can either delete or replace the old version, or you can remove and add back the reference to the DLL in your project. Basically, either way will create a new pointer to the temporary ASP.NET Files.

Is possible you have a wrong nugget versions in assemblyBinding try:
Remove all assembly binding content in web.config / app.config:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.Logging.Abstractions" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.3.0" newVersion="3.1.3.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.DependencyInjection" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.3.0" newVersion="3.1.3.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0" />
</dependentAssembly>
</assemblyBinding>
Type in Package Manager Console: Add-BindingRedirect
All necessary binding redirects are generated
Run your application and see if it works properly. If not, add any missing binding redirects that the package console missed.

For us, the problem was caused by something else. The license file for the DevExpress components included two lines, one for an old version of the components that was not installed on this particular computer. Removing the older version from the license file solved the issue.
The annoying part is that the error message gave no indication to what reference was causing the problems.

I would like to just add that I was creating a basic ASP.NET MVC 4 project and added DotNetOpenAuth.AspNet via NuGet. This resulted in the same error after I referenced a mismatching DLL file for Microsoft.Web.WebPages.OAuth.
To fix it I did a Update-Package and cleaned the solution for a full rebuild.
That worked for me and is kind of a lazy way, but time is money:-P

This exact same error is thrown if you try to late bind using reflection, if the assembly you are binding to gets strong-named or has its public-key token changed. The error is the same even though there is not actually any assembly found with the specified public key token.
You need to add the correct public key token (you can get it using sn -T on the dll) to resolve the error. Hope this helps.

I got this error while building on Team Foundation Server's build-service. It turned out I had multiple projects in my solution using different versions of the same library added with NuGet. I removed all old versions with NuGet and added the new one as reference for all.
Team Foundation Server puts all DLL files in one directory, and there can only be one DLL file of a certain name at a time of course.

My issue was copying source code to a new machine without pulling over any of the referenced assemblies.
Nothing that I did fixed the error, so in haste, I deleted the BIN directory altogether. Rebuilt my source code, and it worked from then on out.

Mine was a very similar situation to the post by Nathan Bedford but with a slight twist. My project too referenced the changed dll in two ways. 1) Directly and 2) Indirectly by referencing a component (class library) that itself had a reference to the changed dll. Now my Visual studio project for the component(2) referenced the correct version of the changed dll. However the version number of the compnent itself was NOT changed. And as a result the install of the new version of the project failed to replace that component on the client machine.
End result: Direct reference (1) and Indirect reference(2) were pointing to different versions of the changed dll at the client machine. On my dev machine it worked fine.
Resolution: Remove application; Delete all the DLLS from application folder; Re-install.Simple as that in my case.

After trying many of the above solutions with no fix, it came down to making sure 'Auto-generate binding redirects' was turned on within your application in Visual Studio.
More information on enabling automatic binding redirection can be found here: https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection

I'll let someone benefit from my shear stupidity. I have some dependencies to a completely separate application (let's call this App1). The dll's from that App1 are pulled into my new application (App2). Any time I do updates in APP1, I have to create new dll's and copy them into App2. Well. . .I got tired of copying and pasting between 2 different App1 versions, so I simply added a 'NEW_' prefix to the dll's.
Well. . . I'm guessing that the build process scans the /bin folder and when it matches something up incorrectly, it barfs with the same error message as noted above. I deleted my "new_" versions and it built just dandy.

My app.config contains a
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>
for npgsql. Somehow on the user's machine, my app.exe.config went missing. I am not sure if it was a silly user, installer glitch, or wacked out anti-virus yet. Replacing the file solved the issue.

I just found another reason why to get this error. I cleaned my GAC from all versions of a specific library and built my project with reference to specific version deployed together with the executable. When I run the project I got this exception searching for a newer version of the library.
The reason was publisher policy. When I uninstalled library's versions from GAC I forgot to uninstall publisher policy assemblies as well so instead of using my locally deployed assembly the assembly loader found publisher policy in GAC which told it to search for a newer version.

To me the code coverage configuration in the "Local.testtesttings" file "caused" the problem. I forgot to update the files that were referenced there.

Just deleting contents of your project's bin folder and rebuild the solution solved my problem.

I faced the same problem while running my unit testcases.
The error clearly states the problem is: when we try to load assembly, the .NET assembly loader tries to load its referred assemblies based on its manifest data (referred assembly name, public key token, version).
To check manifest data:
Open the Visual Studio command prompt,
Type 'ildasm' and drag the required assembly to the ILDASM window and open MANIFEST view. Sometimes MANIFEST contains one assembly with two versions old version as well as new version(like Utility, Version=1.2.0.200 and Utility, Version=1.2.0.203). In reality, the referred assembly is Utility, Version=1.2.0.203(new version), but since the manifest contains even Utility, Version=1.2.0.200(old version), .NET assembly loader tries to find out this versioned DLL file, fails to find and so throws exception.
To solve this, just drag each of the project dependent assemblies to the ILDASM window separately and check which dependent assembly holds the manifest data with the old assembly version. Just rebuild this dependent assembly and refer it back to your project.

A general answer to this kind of issue is to use binding redirects as in other answers. However, that's only part of the problem - you need to know the correct version of the assembly file that you're using. Windows properties is not always accurate and nuget is also not always accurate.
The only way to get correct version info is to analyse the file itself. One useful tool is dotPeek. The assembly name listed in dotPeek is always accurate in my experience.
So for example, the correct binding for this file is the following:
<dependentAssembly>
<assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0"/>
</dependentAssembly>
Windows explorer says the file is 4.6.26515.06, nuget says its a 5.0.0.0 file. dotPeek says it is 4.2.1.0 and that is the version that works correctly in our software. Also note that the public key and culture are important and dotPeek also show this information.

Here's my method of fixing this issue.
From the exception message, get the name of the "problem" library and the "expected" version number.
Find all copies of that .dll in your solution, right-click on them, and check which version of the .dll it is.
Okay, so in this example, my .dll is definitely 2.0.5022.0 (so the Exception version number is wrong).
Search for the version number which was shown in the Exception message in all of the .csproj files in your solution. Replace this version number with the actual number from the dll.
So, in this example, I would replace this...
<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
... with this...
<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
Job done !

The question has already an answer, but if the problem has occurred by NuGet package in different versions in the same solution, you can try the following.
Open NuGet Package Manager, as you see my service project version is different than others.
Then update projects that contain an old version of your package.

clean and rebuild the solution might not replace all the dll's from the output directory.
what i'll suggest is try renaming the folder from "bin" to "oldbin" or "obj" to "oldobj"
and then try build your silution again.
incase if you are using any third party dll's those you will need to copy into newly created "bin" or "obj" folder after successful build.
hope this will work for you.

No solution worked for me. I tried clean project solution, remove bin, update package, downgrade package and so on... After two hours I loaded default App.config from project with assemblies and there I changed wrong reference version from:
<dependentAssembly>
<assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
to:
<dependentAssembly>
<assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
After this I cleaned project, build it again and it worked. No warning no problem.

The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

After signing the third parties assemblies and adding them to GAC I am getting the below error: also the Assembly Binder Log Entry shows this error
It says mismatching assemblies not sure how mistnaching as I deleted all obj and bin fold and batch built the application + reimported the dlls.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\11.0\WebDev.WebServer40.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = AKBARCA\user
LOG: DisplayName = ClubStarterKit.Core, Version=3.0.1.0, Culture=neutral, PublicKeyToken=null
(Fully-specified)
LOG: Appbase =
file:///C:/Users/user/Desktop/NhibernateMediumTrust/NhibernateMediumUpgrade/direct/clubstar
terkit v3 preview/ClubStarterKit.Web/
LOG: DEVPATH = C:\ProgramData\Red Gate\.NET Reflector\DevPath
LOG: Initial PrivatePath =
C:\Users\user\Desktop\NhibernateMediumTrust\NhibernateMediumUpgrade\direct\clubstarterkit v3 preview\ClubStarterKit.Web\bin
Calling assembly : ClubStarterKit.Web, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.

From my experience, this happens, usually once you've published your app and when you have different versions of nuget packages in play. If this happens to be your situation as well, the best way I've found to fix it is to right-click the solution (not the individual projects) and choose "Manage Nuget Packages". Then, locate the offending assembly in the installed packages. You'll probably see it listed multiple times. Click "Manage" on each of the older versions of the package and uncheck all your projects. Once only the latest version of the package remains in the list. Click "Manage" on this one and recheck any projects that need the package. This will essentially upgrade them all to use the same version of the package and should resolve your mismatch error.

I faced similar problem. In my case, I was having multiple projects in my solution.
One of the project was referring EntityFramework 4.0 and that project was being referred in another project that was referring to EntityFramework 5.0. I brought them in sync and the problem got away.

Hum...
I faced something similar with the same error message.
In my case I've updated manually the version of the assemblies.
In the referenced assembly I had another version...
So, I updated it in the web.config.
This solved my problem.
Your === Pre-bind state information === seems incomplete.
Generally it shows the execution and the last line shows the error, so, we can help only sharing our experiences.
Example:
I hope someone else facing this problem find this helpful.

In my case, the error happens when the version specified in web.config's <bindingRedirect> of the dependent assembly (e.g. Newtonsoft.Json) doesn't match the version that is actually in the bin folder. Once the version number in the web.config is updated, the problem is fixed.

When I experienced this problem in the past, I deleted all my project's dll's from the gac, rebuilt the solution, then did iisreset and it was solved.

One way to solve this could be, going under "Manage NuGet Packages for Solution" by doing right click in the solution explorer.
Once there, go to "Consolidate" and find the package that is causing the problems. Make sure that all the projects within the solution are using the same version.

I had a different cause: in my case, I had used various nuget package versions previously, and I had an app.config which for some reason had been automatically generated with this kind of content:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.DependencyInjection" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.1.1.0" newVersion="1.1.1.0" />
</dependentAssembly>
So I only had Version 1.1.0.0 installed, but because of this redirect instruction, it looked for 1.1.1.0 even though Visual Studio had the nuget for 1.1.0.0 installed. Changing the newVersion to 1.1.0.0 fixed everything:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.DependencyInjection" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.1.1.0" newVersion="1.1.0.0" />
</dependentAssembly>

I got this error using FASTjson:
_jsonConfig = fastJSON.JSON.ToObject<jsonConfig>(jsonConfigFileContents);
It failed on this line:
Type t = Type.GetType(typename);
Which causes an exception in System.RuntimeTypeHandle.GetTypeByName
The problem was a difference in the JSON file compared to the JSON Object Model.
The solution is to re-save the JSON Object Model to file, eg:
string jsonSettings = fastJSON.JSON.ToJSON(JSONObjectModel);
File.WriteAllText(JSONFilePath, jsonSettings);