Why is assembly binding redirect not working in my web site?

Question

I have a web site project that I run from Visual Studio using the built in development web server. The virtual path of the web site is set to /

The web.config contains a runtime element with

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="CMS.Controls" publicKeyToken="834b12a258f213f9" culture="neutral" />
      <bindingRedirect oldVersion="4.1.3518.21577" newVersion="4.1.3561.21846" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

I have already removed the xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0" attribute from the root configuration element.

Here is the error:

Could not load file or assembly 'CMS.Controls, Version=4.1.3518.21577, Culture=neutral, PublicKeyToken=834b12a258f213f9' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Here is the log of the binding:

The operation failed.
Bind result: hr = 0x80131040. No description available.
...
LOG: DisplayName = CMS.Controls, Version=4.1.3518.21577, Culture=neutral, PublicKeyToken=834b12a258f213f9
 (Fully-specified)
...
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\Project\WebSite\web.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: CMS.Controls, Version=4.1.3518.21577, Culture=neutral, PublicKeyToken=834b12a258f213f9
...
LOG: Assembly Name is: CMS.Controls, Version=4.1.3561.21846, Culture=neutral, PublicKeyToken=834b12a258f213f9
WRN: Comparing the assembly name resulted in the mismatch: Revision Number

Seems to me like it's ignoring my redirect. I've been looking at it for an hour, do I have a typo or something?

Solution

i know it's been a while, but maybe this can help someone sometime...

We got the exact same problem on some project, it was a webapplication and not a website, but as the problem concern referenced assemblies i don't think the difference of project type is relevant (i may be wrong)

Let's say we have the following assemblies:

• WebApplicationAssembly

  1. CMSControlAssembly
  2. UserManagementAssembly

WebApplicationAssembly is referencing CMSControlAssembly and UserManagementAssembly.

So we tried to do an assemblybinding on CMSControlAssembly, with as much success as you do.

After some digging the lights came up:

the thing is that we used the webcontrols inside CMSControlAssembly directly within our webapplication. (the assemblybinding was set with this in mind)

But CMSControlAssembly was also referenced by UserManagementAssembly, and this was the cause of our problem.

UserManagementAssembly was compiled with a lower version of CMSControlAssembly than the one used by the webapplication.

This lower version of the assembly was nowhere to be found by the webapplication, as the only version provided was the one targeted by the assemblybinding.

So actually the error is not showing a non functional assemblybinding, but the assembly missing for UserManagementAssembly.

Comments

[Martin]

Have you ever found an answer to this?

[Michiel van Oosterhout]

@Martin 4 years I've been waiting... :o I probably found a way to live with it back then, and haven't faced this same problem since.

[Aaron Newton]

I'm not sure if this is helpful, but today I had this issue with OWIN. I had a different version of OWIN referenced (via Nuget) in a libraries project to my main project. The target project had a bindingRedirect in the Web.config that wasn't working. After changing Nuget to reference the newer version used in the library the error went away. The target project's bindingRedirect remained the same other than the newVersion attribute which updated to the new version. The only interesting change that occurred was that the DLL was now included in the references for the .csproj.

[VAV]

Removing the xmlns="schemas.microsoft.com/.NetConfiguration/v2.0" attribute in the root configuration element fix it for me - thank you @michielvoo.

[Gerard ONeill]

Waaaa. I'm still getting what you were getting -- it considers the web.config, and the machine.config and proceeds to refer to the original version. And because someone said that the tiniest of errors can make the process ignore the config, I'm going nearer sighted and stirer crazy! Whoever thought that programming through configuration files was better than code deserves... well.. nevermind.

[Bombinosh]

@Ming If an assembly is referenced several times, the version should be the same in each reference

[EL MOJO]

That doesn't help if it is a third party DLL that is referencing a lower version than the one you have referenced in your project. This is the entire reason bindingRedirect was created.