Upgrade one of two projects using binding redirects

I cannot find information specific to this situation because all information is around upgrading an entire solution rather than one project at a time

The practical situation is that I would like to use the udp appender in log4net and I am upgrading log4net version from 1.2.10.0 to 1.2.15.0 to do so. But I also have an old version of nHibernate referencing and using the API of version 1.2.10.0.

I want to reduce risk of problems in production use of the new version by upgrading only a small subset of the large system. So I would reference the new version only in specific services, while shared components would reference the old version.

Example

Library Project A (nhiberate) references v1 by strong name

Library Project B references v1 by weak name (i.e. just "log4net")

Application Project C:

references Project B's assembly
references Project A's assembly
references v2 weakly
redirects strongly named v1 to v1.dll

Application Project D references Project B and v1 weakly.

Then in Project C I expect all uses of log4net that are not strongly named to use v2, and any more specific references to check the binding redirects in config and then either use the one that is present, or fail.

What actually happens is that Project B also uses the redirect, so I don't benefit from the upgrade.

There must be some metadata in the assembly of Project B that "prefers" to use v1 when it is available. Is that the case? Is it possible to force Project B to use v2 when Project C references v2 (without also causing Project D to fail)?

Example config:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="log4net" publicKeyToken="1b44e1d426115821" />
        <codeBase version="1.2.10.0" href="log4net-1.2.10.0.dll" />
      </dependentAssembly>
    </assemblyBinding>
</runtime>

Solution

ildasm.exe shows me that the assembly contains specific version information in the manifest. It also was easy to create an example solution and show the problem.

https://msdn.microsoft.com/en-us/library/51ket42z(v=vs.110).aspx

explains that

applications run only with the versions they were built and tested with, unless overridden by explicit version policy in configuration files

I expect the metadata can be edited in the copy of the dll used by Project C, and not edited in the copy used by Project D.

However, that's getting a bit complex.

For my purposes it might also be pretty easy to write a udp appender from scratch that didn't have the ip v4/v6 address bug that is in log4net 1.2.10.0

My chosen approach is to upgrade the whole system to use the newer version, and canary the change in a low risk production environment.