Difference between LoadFile and LoadFrom with .NET Assemblies?

Does this clear it up?

// path1 and path2 point to different copies of the same assembly on disk:

Assembly assembly1 = Assembly.LoadFrom(path1);
Assembly assembly2 = Assembly.LoadFrom(path2);

// These both point to the assembly from path1, so this is true
Console.WriteLine(assembly1.CodeBase == assembly2.CodeBase);

assembly1 = Assembly.LoadFile(path1);
assembly2 = Assembly.LoadFile(path2);

// These point to different assemblies now, so this is false
Console.WriteLine(assembly1.CodeBase == assembly2.CodeBase);

Edit: to answer the questions you raised in your revised question, you definitely want to read Suzanne Cook on Assembly Identity.

There are a lot of rules that govern how assemblies are loaded, and some of them have to do with how they resolve dependencies - if your AssemblyA is dependent on AssemblyB, where should .NET look to find AssemblyB? In the Global Assembly Cache, the same directory it found AssemblyA, or somewhere else entirely? Furthermore, if it finds multiple copies of that assembly, how should it choose which one to use?

LoadFrom has one set of rules, while LoadFile has another set of rules. It is hard to imagine many reasons to use LoadFile, but if you needed to use reflection on different copies of the same assembly, it's there for you.

From Suzanne Cook's blog:

LoadFile vs. LoadFrom Be careful - these aren't the same thing. LoadFrom() goes through Fusion and can be redirected to another assembly at a different path but with that same identity if one is already loaded in the LoadFrom context. LoadFile() doesn't bind through Fusion at all - the loader just goes ahead and loads exactly* what the caller requested. It doesn't use either the Load or the LoadFrom context. So, LoadFrom() usually gives you what you asked for, but not necessarily. LoadFile() is for those who really, really want exactly what is requested. (*However, starting in v2, policy will be applied to both LoadFrom() and LoadFile(), so LoadFile() won't necessarily be exactly what was requested. Also, starting in v2, if an assembly with its identity is in the GAC, the GAC copy will be used instead. Use ReflectionOnlyLoadFrom() to load exactly what you want - but, note that assemblies loaded that way can't be executed.) LoadFile() has a catch. Since it doesn't use a binding context, its dependencies aren't automatically found in its directory. If they aren't available in the Load context, you would have to subscribe to the AssemblyResolve event in order to bind to them.

See here.

Also see Choosing a Binding Context article on the same blog.

After a lot of head-scratching I've discovered a difference myself this afternoon.

I wanted to load a DLL at runtime, and the DLL lived in another directory. That DLL had its own dependencies (DLLs) which also lived in that same directory.

LoadFile(): Loaded the specific DLL, but not the dependencies. So when the first call was made from within the DLL to one of those other DLLs it threw a FileNotFoundException.

LoadFrom(): Loaded the DLL that I specified and also all the dependencies that lived in that directory.

Note: If one assembly is loaded using an 8.3 path, and then from a non-8.3 path, they will be seen as different assemblies, even though they are the same physical DLL.

.NET has different load context. Suzanne Cook wrote about them here: https://docs.microsoft.com/en-us/archive/blogs/suzcook/choosing-a-binding-context

This is the way .NET quarantines that references are not mixed up.

one difference that i noticed is:

Assembly.LoadFile - Loads assembly in different AppDomain with limited user rights (diffrence principel). operations like serilization/deserilization could not be performed.

Assembly.LoadFrom- Loads assembly in same AppDomain with same user rights (same principel).

In my case, I just had to simply delete the ASP application cache located @ C:\Windows\Microsoft.NET\Framework\[asp version]\Temporary ASP.NET Files. It is rebuilt when the site is first run. Be sure to stop IIS first.

Hope this helps someone like it did for me.