I use a .NET class exposed as a COM object to the unmanaged world. The assy
containing the class is registered for COM with the /codebase option so that
it's not necessary to register the assy in the GAC. This .NET class
dynamically load assy (let's call them plugins) from various location on the
hard drive not necessarily in the executing assy directory structure.

That's it for the setting, now for the strange behavior:

1) The AppBase taken by the Assembly Loader is the base directory of the
unmanaged executable that created my .NET/COM object. This is
understandable. So if I dynamically load an assembly that reference another
assy that is part of my .NET application, it fails since it check for it in
the base directory of the exectuable that initiated construction of the COM
object. I tested that by copying the referenced assy in that unmanaged app
directory and the binding could be made. This behavior is observed when
using Assembly.Load(byte[]) or Assembly.Load(...).

2) When I use Assembly.LoadFrom(), all of a sudden, the AppBase is now the
base directory of MY .NET application! In other word, the directory of the
executing assembly that dynamically load the "plugin" assembly. Isn't it
strange? The .NET documentation states that, in fact, LoadFrom() gives
supplementals probing hints to the assembly loader as to where to search for
the referenced assy. But what is strange is that none of the "hint"
described in the doc apply to the behavior I observe. LoadFrom() should give
an hint that the referenced assy is in the path of the dynamically loaded
assy. It as nothing to do with the base dir of the executing assy. It's like
calling LoadFrom(...) reset the AppBase "property" of the Assembly Loader
and now it correctly points, more or so, to the executing assy.

Anyway, I find this behavior strange. Am I mystaken? Is it a completely
understandable correct and documented behavior?

Etienne Fortin