Turns out that if you have multiple versions of the same assembly, say 220.127.116.11 and 18.104.22.168 in your probing path, only one of them will ever get loaded. Here's the deal...
I've got an app in
in it are myassembly.dll v22.214.171.124 and myapp.exe.
There's a subdirectory
that contains myassembly.dll v126.96.36.199, plus a new assembly newassembly.dll, which is dependent on v188.8.131.52 of myassembly.dll
In myapp.exe.config, I've included the "new" subdirectory in the applications private path, meaning that it will look there for assemblies when doing assembly binding.
When the application loads newassembly.dll, I would have thought that it would correctly load the 184.108.40.206 version of myassembly.dll, and that the application would load the 220.127.116.11 version to which it was bound. Alas, that turns out not to be the case. Fusion comes back with
LOG: Post-policy reference: myassembly, Version=18.104.22.168, Culture=neutral, PublicKeyToken=xxxyyyzzz
LOG: Cache Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/myapp/myassembly.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\myapp\myassembly.DLL
LOG: Entering run-from-source setup phase.
WRN: Comparing the assembly name resulted in the mismatch: Build Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
We had assumed that fusion would skip the wrong version and keep probing for the right one. It looks like it just finds the wrong one and bails. Of course, if we put both versions in the GAC, it works just like we would expect, which makes sense, that being what the GAC is for and everything.