LoadFrom's Second Bind

Pre-v2, when you load an assembly by path through Fusion (LoadFrom(), ExecuteAssembly(), etc.), it can actually cause two binds, not just one. The first bind loads the file at the given path. If that is successful, another bind is done with the display name of that assembly to see if it's available in the Load context. If it's not available, the LoadFrom() call is still successful - we throw away the results of the second bind. If it is available, we check the path returned from the first bind against the path from the second bind. If they're identical, we keep the Load context IAssembly and throw away the LoadFrom one. (That means that that assembly will be in the Load context, not the LoadFrom context.) Otherwise, we keep the LoadFrom context IAssembly.

This is to ensure that the Load context remains order-independent - an important part of the design for that context. It's an implementation detail, but I bring it up because it has some side-effects that are surprising to customers:

• The second bind shows up in the Fusion log. (It's just another bind to Fusion.) It's unsettling to see a failure in the log (for the second bind) when the LoadFrom() call succeeded.
• Doing a second bind by display name causes probing which slows down the performance of LoadFrom(), especially over http, when the file isn't found immediately.

Fusion has stopping doing the second bind in v2. But, when using an older CLR, customers can avoid both side-effects by putting a redirect from the display name to the codebase in a config file. That will skip probing, helping perf, and, assuming it's the correct codebase, avoid a Fusion log noting an ignorable failure.