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

Question

I am trying to run some unit tests in a C# winforms application (VS 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?

Also, 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

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 but putting it in the GAC or in the application path. Also see http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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

Answer 8

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.

Answer 9

issue resolved with an iisreset

Answer 10

Mine was a very similar situation to the post by Nathan Bedford but with a slight twist. My project too referenced the chagged 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.

Answer 11

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

Answer 12

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.

Answer 13

Tried Glades Mellor deleting the temp asp.net folder and all fixed. Nice