Assembly Binding Redirect to a lower version

Question 1

I'm actually using your first statement for some interop DLLs because the clients in our company have a different state regarding office updates. This is the code I use :

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="office" publicKeyToken="71E9BCE111E9429C" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="11.0.0.0"/>
  </dependentAssembly>
</assemblyBinding>

This provides backwards compatibility from version 14 of the DLL to version 11. Could you provide a link to the DLL u are using?

I've downloaded the NServiceBus framework (version 3.3.8) and investigated the DLL with ILSpy. I would suggest you do the same with your DLL. For my DLL it shows me the same public Key token as yours. Are you sure, that you use version 4.0.0.0 and not verision 3.3.0.0. Or you missmatched the public Key tokens perhaps.

Question 2

According to MSDN: https://msdn.microsoft.com/en-us/library/eftw1fys(v=vs.110).aspx

This value can specify an earlier version than oldVersion.

referring to the newVersion attribute of bindingRedirect. Also in the "Remarks" section:

You can also redirect from a newer version to an older version of the assembly.

Their example is:

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
            <assemblyIdentity name="myAssembly"
                              publicKeyToken="32ab4ba45e0a69a1"
                              culture="neutral" />
            <bindingRedirect oldVersion="1.0.0.0"
                             newVersion="2.0.0.0"/>
         </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

I did notice it also mentions something about Explicit assembly binding redirection in an application configuration file requires a security permission, maybe that's affecting you as well?

Question 3

The answers above are good answers but they are missing important part. And if you read comments, some devs no longer believe this is working. In fact, this is working and working both ways, up version or down

Important: culture

In my experiment, it started to work only when I set culture to neutral. (examples above have 'en-us')

<assemblyIdentity name="..... culture="neutral"/>

In my setup I have WinApp that references Lib1 and Lib3. Lib1 references Lib2 and Lib3. Lib2 references Lib3. And when I push the button, a call propagated all the way from WinApp to Lib3 (both, direct and through chain of libs), and text return displayed on screen. Lib3 is strong named.

Run 1 - no culture set [assembly: AssemblyCulture("")], no binding redirect set - WORKS!

Run 2 - Lower version in Lib3, set binding redirect to 'en-us' - FAIL!

Run 3 - Lower version in Lib3, set binding redirect to 'neutral' - WORKS! Works up-version and down-version.

On other runs - playing with setting [assembly: AssemblyCulture("en-us")] - all attempts failed when AssemblyCulture was not empty. In fact, when set this attribute in WinApp, it wouldn't even compile

Error CS7059: Executables cannot be satellite assemblies; culture should always be empty

So, here we go. Since I don't understand all intricacies of role of the AssemblyCulture I only claim that my experiment only proves that under specific conditions version redirect works fine.

Question 4

If I didn't get you wrong I have done the same thing with stimulsoft report DDLs which I had the latest version installed but I wanted 2010.3 in my application. but not through the config file and redirecting: I simply removed the reference from the solution explorer and added the old DLL refrence, then I set the copy Local property and recompiled so that the DLL would go with application in a same directory, every thing works fine. also done it with some other dlls as well.