bindingRedirect not overcoming ReflectionTypeLoadException

I have a ASP.NET project with a plug-in architecture. I have a strongly named dll dependency in my reference chain, that both the app and the plug-in are dependent on. I'd really like to be able to use some older plug-ins that were compiled against an older version of the dependency dll when the app is updated with new dependency dll.

Currently when I call Assembly.GetTypes() I'm getting a ReflectionTypeLoadException with 5 LoaderExceptions of type FileLoadException, all complaining about the same dll. (There are a lot more dlls in the system, both strongly and weakly named, perhaps dependency chains cause the duplication in LoaderExceptions?)

https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions

I tried adding to my web.config file.

<runtime>
    <assemblyBinding>
        <dependentAssembly>  
            <assemblyIdentity name="Common.Production"  
            publicKeyToken="0e80e12b03b04a71"  
            culture="en-us" />  
            <bindingRedirect oldVersion="2.0.0.1459" newVersion="2.0.0.1463" />  
        </dependentAssembly>

But I still get the same error. I tried adding all the strongly typed dlls I know about in the dependency tree, no change in the error message or quantity of LoaderExceptions.

IL DASM shows I have the key and version correct, although it uses slightly different syntax:

.assembly extern Common.Production
{
  .publickeytoken = (0E 80 E1 2B 03 B0 4A 71 )                         // ...+..Jq
  .ver 2:0:0:1459
}

My log contains the following loader info:

LOG: Using application configuration file: ...\web.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Common.Production, Version=2.0.0.1459, Culture=neutral, PublicKeyToken=0e80e12b03b04a71
...
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

is it possible to ignore assembly manifest mismatch? If the signing key has changed, the bindingRedirect will not work. Another component built against the more recent version (inspected in IL DASM uses the same public key token. It has not changed:

.assembly extern Common.Production
{
  .publickeytoken = (0E 80 E1 2B 03 B0 4A 71 )                         // ...+..Jq
  .ver 2:0:0:1463
}

https://msdn.microsoft.com/en-us/library/ms973843.aspx

• We do not want to store dlls in the GAC, we want the plug-ins using the latest version of the library.
• Version Policy, already tried to implement as above. Tried broadening the range of the application specific policy to oldVersion="0.0.0.0-2.0.0.1459" No Publisher Policy. Machine policy does not mention this assembly.
• .NET Framework Configuration tool? I couldn't find this on my machine.

https://stackoverflow.com/a/7889272/2091951 Maybe? Sounds risky? There shouldn't be types in the assembly I'm not using, this seems like it will bite me later.

http://code.fitness/post/2016/12/assembly-binding-redirect.html

• tried changing to culture="neutral", tried removing culture
• Issue may be further down dependency chain. I've already included all four of the possible culprits I know of to the app.config. How do I find where the culprit is?

Is there a solution open to me other than recompiling the dependency with signing removed and re-releasing all the plug-ins recompiled without the strongly named reference? Nobody in the department (including one former member) has a good reason for why this library was strongly named, but we do have reasons for not wanting to recompile the plugins.

Could not load file or assembly or one of its dependencies

• I'm not getting any results from FusLogvw, and yes I did enable the registry key and restart. The info I'm getting in my log4net log is fairly complete, it does show the processing of the config files and the reason for failure, but I don't see why the web.config items are not applied.

Reference Links:

• How to: Create a Publisher Policy
• Element
• Why strong-name your assemblies?
• Assembly Binding Log Viewer

https://johnnycode.com/2013/07/19/fixing-assembly-binding-redirect-errors/

I had somehow left the xmlns attribute out of my assemblyBinding element.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">