Turns out that if you have multiple versions of the same assembly, say 188.8.131.52 and 184.108.40.206 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 v220.127.116.11 and myapp.exe.
There's a subdirectory
that contains myassembly.dll v18.104.22.168, plus a new assembly newassembly.dll, which is dependent on v22.214.171.124 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 126.96.36.199 version of myassembly.dll, and that the application would load the 188.8.131.52 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=184.108.40.206, 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.