When an Assembly.Load is not really Assembly.Load

This is an interesting discovery I find when I was investigating a regression.

The following code is really Assembly.LoadFrom

                    AssemblyName assemName = new AssemblyName();
                    assemName.CodeBase = pathToAssembly;
                    resultAssembly = Assembly.Load(assemName);

It is the same as

                   resultAssembly = Assembly.LoadFrom(PathToAssembly);

Assembly.Load(AssemblyName) will first attempt to use the assembly name (name,version,culture,publickeytoken) to find the assembly. If that fails, and AssemblyName has a codebase set, CLR loader will attempt an Assembly.LoadFrom with the codebase.

In our example, since the name is empty, loader will directly try Assembly.LoadFrom on the codebase.

Comments (2)

  1. David Levine says:

    And here I thought that was impossible. Does the loaded assembly get loaded into the Load or the LoadFrom context? (See, here’s a case where that little utility I asked about would come in handy)

    I just did a simple test and I was able to load up a DLL from a directory that was not in or under the AppBase. I wish I had known this trick a few years ago…

    If it’s loaded in the Load context, then is this considered to be a bug? If not, this is a real handy way to load an assembly that isn’t under the appbase, or to which you have added a relative path to the private bin path. If it is a bug, how about not fixing it….


  2. It is loaded in LoadFrom context. That is what I mean it is really Assembly.LoadFrom().