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

Answer 1

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.

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

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 4

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 5

Here's my method of fixing this issue.

1. From the exception message, get the name of the "problem" library and the "expected" version number.

2. 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).

3. 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 !

Answer 6

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.