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?

In my case, this happened because I had two projects loading the same DLL with different versions. (hope this helps someone!) — miguelmpn, Apr 15 '20 at 17:22

score 476 · Accepted Answer · edited Feb 22 '20 at 01:13

476

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. Also see https://docs.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference.

edited Feb 22 '20 at 01:13

Callum Watkins

2,444
2
27
42

answered Oct 18 '08 at 13:39

Lars Truijens

40,852
6
117
137

22

but when i look at references of the project, it is pointing to 1.2.0.203 .. . nothing seems to be pointing to 1.2.0.200 anymore – leora Oct 18 '08 at 13:40
129

Exactly - it's *looking* for 1.2.0.203, but it *found* 1.2.0.200. Find out where that file is and replace it with the right version. – Jon Skeet Oct 18 '08 at 13:44
20

I asked a similar question here and got a working solution: http://stackoverflow.com/questions/4187907/net-picking-wrong-referenced-assembly-version – Michael La Voie Nov 15 '10 at 20:12
15

Check the references version, and then look if its the same in packages.config and Web.config – zdarsky.peter Oct 31 '14 at 19:46
1

details on running fuslogw as referenced in the above link to JunFeng blog http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57120.aspx – hello_earth Nov 06 '14 at 10:12
In my case under Build > Publish, I had "Delete all existing files prior to publish" unchecked, so it was using an old version of the DLL on the server and wasn't overwriting it with the newer version I had locally. Once I checked that it pushed the right version to IIS and fixed it. – James Toomey Jun 23 '16 at 22:27
I had this error with a nuget package that was totally missing. When I went to nuget and installed the package the error was fixed. – niico Apr 30 '18 at 08:36
@Lars Truijens how did you know it found 1.0.200? I can't see `200` mentioned in the OP's stacktrace? – Chillin' Sep 14 '18 at 14:12
1

@OnlineUser02094: It says so literally in the Exception Message: Version=1.2.0.200 – Lars Truijens Sep 14 '18 at 14:49
7

This message confuses me every time. It seems to be written backwards. I'd expect it to complain about the version you've asked to load, not the version it found. Glad I'm not the only one who gets it wrong! – Greg Woods Nov 02 '18 at 16:34
I searched for the offending assembly in nuget, installed it (with a new version) and the problem disappeared. – SimonKravis Nov 28 '18 at 00:46
1

I was having an identical error on an Azure function project and with the help of fuslogvw.exe @ra170 identify that assemblyIdentity Microsoft.Azure.Storage.Common" was missing from func.exe.Config. So I added this : ` ` – Carlos Busca Feb 21 '19 at 15:24
In my case somehow `Web.config` file was simply missing and I get the above error. – endo64 Aug 22 '19 at 06:47
I thought the `Web.config` was there, but the account I used on the production server had the setting to hide known file extensions. So in the Windows Explorer I saw a `Web.config`, which was in fact `Web.config.txt`. – H. de Jonge Nov 27 '19 at 16:29
Problem appears only when installing over an existing installation using VS2019 installer (with uninstall earlier version checked). Seems to be looking for the earlier install version of the dll. – SimonKravis Oct 17 '20 at 23:14
The problem was caused by a reference to DLL with v 106.8.10.0 in the earlier version of the project and the DLL v 105.2.3.0 referenced from DLL2 which appeared in the later version. Because the referenced version from DLL2 (detected with Dependencies) was earlier than the DLL already present from the earlier version, it wasn't replaced by the new version so DLL2 referencing v 105.2.3.0 failed as it wasn't there. Fix was to download the open source for the DLL2 referencing DLL 105.2.3.0 and rebuild it with the latest version 106.11.7.0. This needed an update to nuget.exe! – SimonKravis Oct 21 '20 at 00:18

score 93 · Answer 2 · edited May 23 '17 at 12:10

93

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.

edited May 23 '17 at 12:10

Community

1
1

answered Oct 20 '08 at 21:31

Seth Petry-Johnson

11,227
6
44
68

19

Don't forget that the File Version is not part of the assemblies identity. The Assembly Version is, but does not have to be the same as the File Version! – Lars Truijens Dec 06 '11 at 08:10
If using fuslogvw for services read http://blogs.msdn.com/b/junfeng/archive/2004/02/14/72912.aspx – Nick Sep 28 '15 at 15:23
Searching for the filename solved my problem. I had an old version of the dll in my Temporary ASP.Net folder and InstallShield was using that instead of the up to date version! Clean solution, rebuild, restart PC did nothing. Worked fine locally and blew up every time it was deployed. – JumpingJezza Dec 02 '15 at 03:24
Immediately after building, my site works fine, but a little while later, this problem crops up. – Shavais Apr 14 '17 at 15:27
I edited this answer to say assembly version instead. – Worthy7 Apr 18 '19 at 09:22
– access_granted Apr 18 '20 at 05:37

score 61 · Answer 3 · answered Nov 17 '09 at 19:15

61

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.

answered Nov 17 '09 at 19:15

Nathan Bedford

8,394
5
32
29

2

+1 Something similar happened to me when I have one of my DLLs reference an older version of Caliburn Micro. – Jason Massey Feb 01 '13 at 23:48
me too, your experience sparked me where I need to look and I got my issue fixed. – Esen Feb 06 '13 at 16:56
Another option would be to open the `CompanyControls` project, right-click the `CompanyClasses.dll` reference --> properties --> `SpecificVersion = false` – BlueRaja - Danny Pflughoeft Oct 04 '13 at 22:43
this is very often case on xamarin applications. I had xamarin.forms project different than xamarin.droid project. I just saw your post and I recognized it. – Emil Mar 06 '16 at 19:12
If CompanyClasses.dll is signed, then `SpecificVersion = false` alone won't cut it. You'll need a `bindingredirect`. – Denise Skidmore May 11 '18 at 15:57

score 56 · Answer 4 · edited Dec 03 '17 at 17:27

56

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.

edited Dec 03 '17 at 17:27

Peter Mortensen

28,342
21
95
123

answered Nov 02 '12 at 00:34

Yaniv.H

750
6
5

1

This worked for me. I changed the 'newVersion=3.3.3' to 'newVersion=3.1.0' – jward01 Feb 01 '16 at 21:13
Best not to go down the rebinding route if you can avoid it though. When that bug comes to bite you it'll bite hard. – BanksySan Dec 08 '16 at 14:57
1

My issue was the fact that the redirects were pointing to non-existent assemblies.The App.Config held assembly info from the latest NuGet packages I'd installed. When I downgraded these packages later, it did NOT clean this up. This was a .NET standard class library being hit by a 4.7.2 framework unit test project. The unit test project's issue presented at runtime.. – D-Sect Oct 26 '18 at 16:44
@D-Sect is right. If your source control indicates that web.config has changes (because you've been playing with your NuGets) you might be wise to back those bindingRedirects out of there. Downgrading NuGets will not clean up the binding redirects – bkwdesign Nov 01 '18 at 20:24

score 45 · Answer 5 · answered Jul 13 '10 at 03:27

45

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

answered Jul 13 '10 at 03:27

Tad

491
4
2

16

This is usually the solution for me. Often, deleting `bin` and `obj` do it. Basically, something I used to reference is still sitting there trying to satisfy the same requirement. For example, an old version being something I referenced directly and the new version being on NuGet. – David Betz Oct 15 '16 at 15:34
Encountered this problem for several DLLs after pulling from TFS. This solution fixed it for me. – Milo Mar 14 '18 at 18:24
3

Worked for me. Deleted out the bin amd obj folder and resolved the issue. – user1619480 Jul 20 '18 at 09:29
Thanks, worked for me also, just deleting the bin folder. – The Cookies Dog Nov 12 '18 at 16:58
For me it was enough to delete `bin` folder. Surprisingly, I tried _clean solution_ and _rebuild solution_ before without success. Sometimes a bit strange. – Lion Aug 10 '19 at 17:43
1

"Clean solution" didn't do anything for me. (Microsoft????) But deleting the bin and obj folders fixed it. Thanks! – Mmm Dec 10 '19 at 16:51

RayLoveless · Answer 6 · 2019-02-27T18:48:31.283

40

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. enter image description here

edited Feb 27 '19 at 18:48

answered Jun 28 '13 at 17:21

RayLoveless

16,084
19
68
90

9

That setting has only effect at *compile time*. After it is compiled, it will need the exact same assembly version with which you compiled it. See http://stackoverflow.com/questions/24022134/how-exactly-does-the-specific-version-property-of-an-assembly-reference-work-i – Lars Truijens May 12 '17 at 12:12

codeMonkey · Answer 7 · 2019-01-28T04:19:15.520

28

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

edited Jan 28 '19 at 04:19

answered Jan 24 '19 at 19:27

codeMonkey

2,788
2
25
41

1

Worked for me as well. Thanks – Oleh Udovytskyi Apr 01 '19 at 14:15
1

you saved my time – Abdu Imam Apr 25 '19 at 10:44
9

this works only when package management format is packages.config, if you are using 2017 csproj without packages.config, it doenst work :( – ManiVI Jun 22 '19 at 00:41
2

Mind officially blown – BGilman Oct 29 '19 at 15:33
I believe that new-style csproj projects will automatically generate binding redirects in app.config files on build (the redirects don't need to be added to project app.config files, but will exist in the output). – Mike Rosoft Jul 02 '20 at 07:39
2

I had updated this product over time... sometimes just flushing the artifacts and having a do over is needed. I think the only thing different I could have done was create a new project and hand pick the elements into it... this command saved me from having to do that... Someday I will have to pay the technical debt? Maybe, but not today evil. – Hunter-Orionnoir Jan 20 '21 at 05:39

score 24 · Answer 8 · edited Apr 01 '17 at 08:07

24

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>

edited Apr 01 '17 at 08:07

Peter Mortensen

28,342
21
95
123

answered Mar 05 '14 at 16:22

frattaro

2,612
1
12
9

I've seen this where, at least for the Entity Framework module when you use NuGet, if you right-click your solution, go to Manage NuGet Packages for Solution, then Installed Packages > All, select that module, select Manage, you can usually deselect it from your project. That should clean out things like this without having to do it manually --- assuming the vendor did their due diligence. But good catch as apparently sometimes they don't, if that's how you removed it. – vapcguy Aug 07 '14 at 02:08

score 23 · Answer 9 · answered Oct 09 '16 at 18:34

23

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.

answered Oct 09 '16 at 18:34

Levi Fuller

9,146
4
34
41

3

Thanks, Levi Fuller.This answer should be higher up; for my situation it was spot on! For me this error started when I made a backup copy of my web.config and Visual Studio kept loading this config file instead of the actual config, even after I deleted the duplicate copy. This solved it. Thanks. – BruceHill Sep 24 '17 at 05:08
Works for me too. Still unsure why this works though :( – KangarooWest Oct 12 '17 at 22:21
Thank you so much. This finally got it working after hours of troubleshooting. In my case, the problem happened after I accidentally upgraded some NuGet packages, then reverted the changes in my working copy (packages.config, .csproj). – Sam May 25 '21 at 07:16

score 22 · Answer 10 · answered Sep 03 '09 at 00:00

22

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.

answered Sep 03 '09 at 00:00

Neal Tibrewala

436
3
7

We just migrates to a different server had this issue cause we keep backups. Worked after deleting backup copies. Thanks :) – Jtuck Dec 29 '18 at 18:09

score 14 · Answer 11 · answered Sep 15 '10 at 17:07

14

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.

answered Sep 15 '10 at 17:07

Glade Mellor

1,226
16
9

3

This worked for me when I closed Visual Studio, stopped IIS, and deleted all temporary ASP.NET files. Note there can be files in the Framework and Framework64 folder if on 64 bit machine, as well as in the .NET 2.0 and 4.0 folders! – Bryan B Aug 12 '11 at 16:19
I used the Windows Start Menu search function to find all DLLs created by my solution and then deleted the whole lot, wherever they were found. I could do this without fear because they should only be created during my Visual Studio debugging. As VS will rebuild such missing DLLs and nothing outside of my solution should be referencing them, this was a "safe" operation for me. – Zarepheth Jun 18 '14 at 19:32

score 8 · Answer 12 · answered Nov 23 '09 at 11:09

8

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.

answered Nov 23 '09 at 11:09

Sire

3,620
3
33
67

2

In my case, after upgrading to new DevExpress version, the .resx file of a form contained references to old uninstalled library version. I had to open .resx in code view and either correct the version to new one or delete the invalid entries. – Artemix Oct 20 '11 at 21:58

score 6 · Answer 13 · answered Jul 16 '10 at 21:22

6

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.

answered Jul 16 '10 at 21:22

Guy Starbuck

20,727
6
51
63

1

Please elaborate - what is "sn -T"? And where do I add the public key token? – Moritz Both Sep 29 '10 at 08:03
4

"sn.exe" is a tool that comes with Visual Studio, it's a command line tool that can be run from the Visual Studio command prompt. Just run the Visual Studio command prompt (from the start menu), navigate to the folder that contains your assembly, and type "sn -T " where is the full name of the dll. This gets the Assembly "Token" information. Once you have this, when you are doing late binding with reflection, enter the token info into the assembly id string (i.e., "Assembly=MyAssembly.dll, Public Key Token=) – Guy Starbuck Sep 29 '10 at 14:57
2

Thanks for this answer. I was getting this error when referencing a Configuration Section in my App.ini. I had recently signed the assembly, so the PublicKeyToken=null had to be updated with the new (correct) token. – Liam Oct 19 '10 at 06:53

score 5 · Answer 14 · edited Dec 03 '17 at 17:26

5

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.

edited Dec 03 '17 at 17:26

Peter Mortensen

28,342
21
95
123

answered Oct 01 '12 at 21:34

Thomas

3,272
4
32
45

score 5 · Answer 15 · edited Nov 26 '17 at 00:22

5

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

edited Nov 26 '17 at 00:22

Peter Mortensen

28,342
21
95
123

answered Jun 28 '13 at 23:17

Ben Pretorius

3,641
2
29
28

2

Similar answer for me. `Update-Package -reinstall` re-installs all NuGet packages at the same version. – Jess Mar 13 '17 at 13:08
2

This is great; thanks for posting. I tried all of these other great suggestions, but this was the solution that did the trick. Thank goodness for people who are still willing to post an alternate solution, even when there are 80 of them available – Hambone Jul 13 '18 at 15:11

score 5 · Answer 16 · edited Dec 03 '17 at 17:22

5

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.

edited Dec 03 '17 at 17:22

Peter Mortensen

28,342
21
95
123

answered Jul 16 '15 at 08:28

cederlof

6,530
4
39
59

1

Another way is to click "Manage NuGet packages for solution..." and update both your test project and the project under tests to the same (newest) version. – lixonn Oct 19 '15 at 22:46

score 5 · Answer 17 · edited Sep 16 '13 at 11:05

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.

score 4 · Answer 18 · answered Apr 27 '12 at 23:20

4

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.

answered Apr 27 '12 at 23:20

AEON Blue Software

41
1

Cole · Answer 19 · 2020-06-24T19:56:05.353

4

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://docs.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection

edited Jun 24 '20 at 19:56

answered Jun 24 '20 at 19:12

Cole

51
2

score 4 · Answer 20 · answered Mar 13 '12 at 15:32

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.

score 3 · Answer 21 · answered Jun 01 '12 at 13:07

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.

score 3 · Answer 22 · answered Mar 04 '13 at 09:04

3

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

answered Mar 04 '13 at 09:04

uli78

1,004
1
19
27

score 3 · Answer 23 · answered Aug 10 '17 at 04:15

3

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

answered Aug 10 '17 at 04:15

dhiraj1mumbai

51
5

1

Well what do you know, you just helped me out my misery, thanks indeed – Ronny Mahlangu Jun 12 '18 at 07:08

score 2 · Answer 24 · edited Dec 03 '17 at 03:25

2

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.

edited Dec 03 '17 at 03:25

Peter Mortensen

28,342
21
95
123

answered May 11 '17 at 23:35

erhan355

588
8
16

score 2 · Answer 25 · answered Dec 03 '17 at 18:39

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.

score 2 · Answer 26 · edited Aug 25 '19 at 16:44

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.

score 2 · Answer 27 · answered Dec 11 '20 at 14:14

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.

score 1 · Answer 28 · answered Jun 06 '14 at 09:27

1

Manually deleting the old assembly from folder location and then adding the reference to new assemblies might help.

answered Jun 06 '14 at 09:27

rjain

30
3

score 1 · Answer 29 · edited Dec 03 '17 at 17:21

In my case the problem was between the chair and the keyboard :-)

Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)

Two or more different assemblies wanted to use a different version of the DotNetOpenAuth library, and that would not be a problem. Furthermore, on my local computer a web.config was automatically updated by NuGet:

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

Then I realized that I had forgot to copy/deploy the new web.config to the production server. So if you have manual way of deploying web.config, check it is updated. If you have completely different web.config for production server, you have to merge these dependentAssembly section in sync after using NuGet.

score 1 · Answer 30 · edited Apr 29 '15 at 13:33

I got the same error... In my case it got resolved as follows:

At first when the application was installed then the people here had used Microsoft Enterprise Library 4.1 in the application.
In previous week my machine was formatted & after that today when I built that application then it gave me an error that Enterprise Library assembly is missing.
Then I installed Microsoft Enterprise Library 5.0 which I got on Google as first search entry.
Then when I built the application then it gave me the above error i.e. The located assembly's manifest definition does not match the assembly reference.
After much of a search work & analysis, I found that application was referring 4.1.0.0 & the DLL in the bin folder was of the version 5.0.0.0
What i did was then I installed the Microsoft Enterprise Library 4.1.
Removed the previous reference(5.0) & added the 4.0 reference.
Built the application & voila...it worked.

score 1 · Answer 31 · answered Nov 15 '16 at 16:00

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 !

what if my csproj files have no version referenced? – John Demetriou Apr 25 '17 at 11:07 — John Demetriou, Apr 25 '17 at 11:07

Jaggan_j · Answer 32 · 2018-06-15T15:27:10.340

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.

ChrisBeamond · Answer 33 · 2020-12-03T12:36:05.783

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.

!!!!!!!!!!This worked instantly : Note that the binding for me that worked was related to the oldVersion -> newVersion. My assembly manifest pointed to the old version, but was never redirected to the new version of the assembly after upgrading to a later of the same DLL. — Reinhard Behrens, Apr 21 '21 at 05:27

score 1 · Answer 34 · answered Jan 15 '21 at 10:12

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

score 0 · Answer 35 · edited Dec 03 '17 at 17:25

0

I had a similar problem when attempting to update one DLL file of my web-site.

This error was occurring, when I simply copied this DLL file into bin folder over FTP.

I resolved this problem by:

stopping the web-site;
copying needed DLL file/DLL files;
starting the web-site

edited Dec 03 '17 at 17:25

Peter Mortensen

28,342
21
95
123

answered Sep 06 '12 at 07:20

magicmanam

36
3

score 0 · Answer 36 · edited Dec 03 '17 at 17:34

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.

Unfortunately, I can't drag the assembly to ildasm since the error prevents the assembly from being built... — Number8, Apr 11 '13 at 11:07
This sounds promising but I don't understand how to fix it. I have located a project in my solution that has two versions System.Web.Mvc. When I rebuild it, it still contains two versions. How can I get rid of the reference to the old version? — mike nelson, Jul 14 '13 at 05:18

score 0 · Answer 37 · answered Jul 30 '13 at 05:43

0

In your AssemblyVersion in AssemblyInfo.cs file, use a fixed version number instead of specifying *. The * will change the version number on each compilation. That was the issue for this exception in my case.

answered Jul 30 '13 at 05:43

DevXP

27
1

score 0 · Answer 38 · answered Jan 24 '14 at 16:01

I ran into this issue while using an internal package repository. I had added the main package to the internal repository, but not the dependencies of the package. Make sure you add all dependencies, dependencies of dependencies, recursive etc to your internal repository as well.

score 0 · Answer 39 · answered Aug 01 '14 at 13:55

I had the same issue today which prevented me from performing Add-Migration after I made changes in Entity Framework.

I had two projects in my solution, let's call them "Client" and "Data" - a class library project which held my EF models and context. The Client referenced the Data project.

I had signed both projects, and then later made changes to an EF model. After I removed the signature I were able to add the migrations, and could then signed the project anew.

I hope this can be useful for someone, sparing them of prolonged frustration..

score 0 · Answer 40 · edited Apr 01 '17 at 08:09

0

I had this problem after starting to use InstallShield. Even though the build order showed the installation project to be last it was building out of order.

I corrected this by making every other project dependent upon it - this forced the installation to build last and thereby removed my assembly mismatching. I hope this helps.

edited Apr 01 '17 at 08:09

Peter Mortensen

28,342
21
95
123

answered Sep 22 '14 at 15:50

Tim

81
3

score 0 · Answer 41 · answered Dec 04 '15 at 08:57

0

This can also occur if you are using both AssemblyInfo.cs with the AssemblyVersion tags and your .csproj file has with a different value. By either matching the AssemblyInfo or removing the section all together the problem goes away.

answered Dec 04 '15 at 08:57

netniV

1,998
1
13
22

score 0 · Answer 42 · answered Jan 18 '17 at 23:45

OK, one more answer. I previously created my app as 64 bit and changed the output path (Project/Properties/Build/Output/Output Path) accordingly. Recently I changed the app to 32 Bit (x86), creating a new output path. I created a shortcut to where I thought the compiled .exe was going. No matter what I changed about the source, it got the manifest not matching error. After about an hour of frustration, I happened to check the date/time of the .exe file, saw it was old obviously referencing old .dll's. I was compiling the app into the old directory and my shortcut was referencing the newer. Changed the output path to where the .exe should go, ran the shortcut and error is gone. (slaps forehead)

score 0 · Answer 43 · answered Jan 10 '18 at 16:19

0

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

answered Jan 10 '18 at 16:19

Bellatorius

75
6

score 0 · Answer 44 · edited Jun 20 '20 at 09:12

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

score 0 · Answer 45 · answered Jan 25 '19 at 22:11

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

score 0 · Answer 46 · answered Apr 18 '19 at 08:45

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.

score 0 · Answer 47 · answered May 22 '19 at 06:59

0

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

answered May 22 '19 at 06:59

Marzie Keshavarz

21
6

score 0 · Answer 48 · answered May 29 '19 at 11:35

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

Mostafa Vatanpour · Answer 49 · 2019-10-12T06:32:21.150

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.

score 0 · Answer 50 · answered Nov 16 '19 at 11:37

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.

score 0 · Answer 51 · answered May 31 '20 at 16:59

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.

score 0 · Answer 52 · answered Jul 28 '20 at 07:05

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>

Marek Schwarz · Answer 53 · 2021-02-27T12:53:11.870

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.

score 0 · Answer 54 · answered Jul 12 '11 at 02:24

I received this error message due to referencing an assembly that had the same name as the assembly I was building.

This compiled but it overwrote the referenced assembly with the current projects assembly - thus causing the error.

To fix it I changed the name of the project, and the assembly properties available through right-clicking on the project and choosing 'Properties'.

score 0 · Answer 55 · answered Apr 07 '21 at 00:10

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://docs.microsoft.com/en-us/nuget/consume-packages/migrate-packages-config-to-package-reference#migration-steps

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

Open a solution containing project using packages.config.

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

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.

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

Review any package compatibility issues.

Select OK to begin the migration.

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.

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

Vikrant · Answer 56 · 2019-12-05T18:38:40.107

-1

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.

edited Dec 05 '19 at 18:38

answered Aug 25 '19 at 05:10

Vikrant

850
8
17

What is "Full details"? – Shay Oct 16 '19 at 16:22
Please start debugging in Visual Studio. Visual Studio will throw an exception on reaching the piece of code. Please see "Show details" in the Visual Studio's Exception UI at the bottom. I also edited my answer with more details. – Vikrant Dec 05 '19 at 18:36

score -4 · Answer 57 · answered Jul 01 '10 at 13:59

-4

Try adding whatever's missing to the global assembly cache.

answered Jul 01 '10 at 13:59

nikonica

15

Actually, I don't get the downvotes. When a reference is missing, sometimes adding it to the GAC actually IS the answer, ASSUMING that is where the reference is pointed. I agree this answer could've been phrased as a direct response to the author's question, a link on how to get it in the GAC, but let's not penalize for a general answer -- especially with the other branching on here, already. I see SO as a bunch of possible answers to the error type, not just the specific scenario. And they don't have over 50 rep, so they can't add a comment to the question or posts (which IMHO should change). – vapcguy Aug 07 '14 at 02:42

score -4 · Answer 58 · answered Sep 01 '10 at 19:41

-4

Right click the reference in VS set "Specific Version" property to True.

answered Sep 01 '10 at 19:41

Adam

9
1

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

58 Answers58

Linked

Related