The located assembly's manifest definition does not match the assembly reference

Question

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?

Answer 1

There are so many answers to this question, and since not all are relevant to my situation, I couldn't review them all in detail. So please forgive me if my answer is redundant. My situation was due to NuGet package management in Visual Studio 2012. To address it, I placed my Nuget package in a central location and checked all the project references to make sure they were pointing to this package (adding or removing them as appropriate). One caveat, when that still didn't solve the problem, I checked my Reference Paths (under the project's Properties->References->Reference Paths... or Properties->Reference Paths, depending on the project) to make sure the correct reference path was listed. This last step will not be necessary for all projects, so should probably only be used as needed.

Answer 2

I was stuck in the similar issue . Unloaded the solution file and clicked on edit in csproj searched for particular dll, went to the path of the dll packages folder , found out there were two different versions of dll having same name so deleted the old one and now builded successfully.

Hope this helps somebody.

Answer 3

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.

Answer 4

It's not uncommon for .DLLs to report a different version using reflection's Version property in code compared to in the File Explorer's > Properies > Details tab.

Over the years I found that using this bit of powershell works better to find which version you should set your binding redirect to.

[Reflection.AssemblyName]::GetAssemblyName('C:\Source\Project\Web\bin\System.Memory.dll').Version

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      1      2

From the above I can insert (or replace) the binding redirect in my app.config file:

<dependentAssembly>
    <assemblyIdentity name="System.Memory" culture="neutral" publicKeyToken="cc7b13ffcd2ddd51"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.1.2" newVersion="4.0.1.2"/>
</dependentAssembly>

---

In that particular example the file version reported by the Details tab for System.Memory.dll was 4.6.31308.01.

Answer 5

In My case, None of above solutions worked - issue was caused by old .net configuration (2.0) schema defined in app.config because of which bindingRedirect was not working.

Remove xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0" from app.config or web.config, as it seems like bindingRedirect is not supported in older versions of .net framework like 2.0

Hopefully, this will save someone few Hours or Days.

Answer 6

Running the migrator to upgrade from using packages.config to PackageReference painlessly fixed this error for me. If you're running Visual Studio 2017 Version 15.7 or later, you can upgrade by following the steps below.

https://learn.microsoft.com/en-us/nuget/consume-packages/migrate-packages-config-to-package-reference#migration-steps

Here are the steps (copied from the above link):

1. Open a solution containing project using packages.config.

2. In Solution Explorer, right-click on the References node or the packages.config file and select Migrate packages.config to PackageReference....

3. The migrator analyzes the project's NuGet package references and attempts to categorize them into Top-level dependencies (NuGet packages that you installed directly) and Transitive dependencies (packages that were installed as dependencies of top-level packages).

Note: PackageReference supports transitive package restore and resolves dependencies dynamically, meaning that transitive dependencies need not be installed explicitly.

4. (Optional) You may choose to treat a NuGet package classified as a transitive dependency as a top-level dependency by selecting the Top-Level option for the package. This option is automatically set for packages containing assets that do not flow transitively (those in the build, buildCrossTargeting, contentFiles, or analyzers folders) and those marked as a development dependency (developmentDependency = "true").

5. Review any package compatibility issues.

6. Select OK to begin the migration.

7. At the end of the migration, Visual Studio provides a report with a path to the backup, the list of installed packages (top-level dependencies), a list of packages referenced as transitive dependencies, and a list of compatibility issues identified at the start of migration. The report is saved to the backup folder.

8. Validate that the solution builds and runs. If you encounter problems, file an issue on GitHub.

Answer 7

Is possible you have a wrong nugget versions in assemblyBinding try:

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

2. Type in Package Manager Console: Add-BindingRedirect
3. All necessary binding redirects are generated
4. Run your application and see if it works properly. If not, add any missing binding redirects that the package console missed.

Answer 8

I had the same error but in my case I was running a custom nuget package locally into another project.

What fixed it for me was changing the package version to the version requested in the error.

The package was in netstandard 2.1 and the project requesting the package was in netcore 3.1

Answer 9

This question is quite old, and I had the same error message recently with Azure DevOps Yaml pipelines and Dotnet Core 3.1. The problem was somewhat different than the other answers try to solve, so I will share my solution.

I had a solution with many projects for my own nuget packages. I had by accident added version-tag in the *.csproj files like this:

  <Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <Version>1.0.0</Version>
  </PropertyGroup>

I packed the nuget packages for all projects using Yaml with a DotnetCoreCLI@2 task:

 - task: DotNetCoreCLI@2
   displayName: 'pack'
   inputs:
     command: pack
     nobuild: true
     configurationToPack: 'Release'
     includesource: true
     includesymbols: true
     packagesToPack: 'MyNugetProject1.csproj;**/MyNugetProject2.csproj'
     versioningScheme: 'byEnvVar'
     versionEnvVar: 'GitVersion.SemVer'

The problem was that the version in the *.csproj files didn't match the version in the environment variable GitVersion.SemVer (specified by input-"versionEnvVar").

After removing all <Version>1.0.0</Version>-tags in the *.csproj files the assembly/fileversion for dll was automatically assigned by the environment-variable and both nuget and dll (assembly/fileversion) would have the same version and problem was solved.

Answer 10

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.

Answer 11

Try removing the assembly refernce from your webConfig/appConfig

 <dependentAssembly>
        <assemblyIdentity name="System.IO" publicKeyToken="B03F5F7F11D50A3A" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.3.0.0" />
      </dependentAssembly>

Answer 12

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

Answer 13

I got stumped with this for a while. I could build and run in release, couldn't in debug due to a reference that didn't match match the manifest. I must have checked the references a hundred times, and deleted all dll's. I noticed that the generated manifest in debug and release were different.

I deleted the app.manifest in my project/properties and it fixed the problem. This didn't include mention of the offending referenced dll's - so I don't know why this was causing a problem.

Answer 14

Please run the code in Visual Studio debugger. Please run till you get the exception. There will be Visual Studio Exception UI. Please read the "full details" /"Show details" at the bottom of Visual Studio Exception. In Full details/Show details, it told me that one of my project (which was referring to my main project has a different version of Microsoft.IdentityModel.Clients.ActiveDirectory). In my case, my unit test project was calling my project. My unit test project and my project has a different version of Microsoft.IdentityModel.Clients.ActiveDirectory. I am getting run time error when my unit test were executing.

I just updated the version of my unit test project with the same version of main project. It worked for me.

Answer 15

Solved my issue like this with brute force.

I realised I hand multiple copies of the DLL all over the solution and two different versions.

Went into the solution in explorer, searched for the offending DLL and deleted all of them. Then added the references to the DLL back using the one version of the DLL.

Answer 16

I had similar problem but no answer worked for me.

The solution that worked for me was removing publicKeyToken part from project file(YourProject.csproj) manually.

Previously it had been:

<Reference Include="Utility, Version=0.0.0.0, Culture=neutral, PublicKeyToken=e71b9933bfee3534, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>dlls\Utility.dll</HintPath>
</Reference>

After change it was:

<Reference Include="Utility, Version=1.0.1.100, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>dlls\Utility.dll</HintPath>
</Reference>

Be sure that SpecificVersion is False.

Answer 17

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.

Answer 18

Happened to me for System.ValueTuple

Unexpected Error Could not load file or assembly 'System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.

Solved it by installing .NET Framework 4.7.2 Runtime on the machine the error occurred on. Simple and no need to add bindingRedirect, modifying GAC or downgrading NuGet packages etc.

https://dotnet.microsoft.com/download/dotnet-framework/net472

Answer 19

check the licenses.licx in properties of project you will find the wrong version there.... it worked for me in active report refrences

Answer 20

I was getting:

Could not load file or assembly 'XXX-new' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

It was because I changed the name of the assembly from XXX.dll to XXX-new.dll. Reverting name back to the original fixed the error.

Answer 21

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.

Answer 22

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

Answer 23

This same error was surfacing for me in my Unit Tests project and resulting in some failing tests. I double-checked which version of the assembly I was using in assembly explorer and checked the contents of the runtime/dependentassembly tags and realized a different version of the assembly I had been using was still being referenced there. Because this was the only directive in my tests project app.config I just tried deleting the entire app.config file, rebuilding the solution, and that did the trick! No more reference errors for me :)

Answer 24

Had similar issue mentioned at this post "Any suggestions on how I figure out what is trying to reference this old version of this DLL file?"

Needed which assembly still refers old ODATA client 6.15.0 , the ildasm helped to narrow down for me (without base code access, only via deployed pkg at server).

Screen shot below for quick summary.

DeveloperPackge if don't have ildasm.exe https://www.microsoft.com/net/download/visual-studio-sdks

Answer 25

If you ever get an error like "The located assembly's manifest definition does not match the assembly reference" and if you have updated via Project > Manage NuGet Packages and Update tab in VS, the first thing you could do is try installing another version of the package after checking versions from NuGet Gallery page and running the folowing command from Package Manager Console:

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

Although answer is not directly related to the package in question and it was asked way back, it is kind of generic, still relevant and hope it helps someone.

Answer 26

The problem with me was that there were old dll's dployed that were deleted in a new build. To fix it, I just checked the box to remove additional files at destination when publishing. Remove additional files at destination

Answer 27

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.

Answer 28

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:

1. Open the Visual Studio command prompt,
2. 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.

Answer 29

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.

Answer 30

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.