Why would I use Assembly.LoadFile in lieu of Assembly.LoadFrom?

It's my impression that Assembly.LoadFrom uses the ApplicationBase and PrivateBinPath. It also my impression that Assembly.LoadFile does not.

Why would anyone want to use LoadFile? In other words, if my understanding is correct, why would anyone want to NOT use the ApplicationBase and PrivateBinPath?

I'm working with some existing code, which uses LoadFile, and I don't understand why it would do so. LoadFile apparently does not load dependencies from the same directory. The LoadFrom method does load dependencies (From the doc: The load-from context...allows dependencies on that path to be found and loaded because the path information is maintained by the context.) I'd like to convert it from using LoadFile, to use 开发者_如何学JAVALoadFrom.

What is likely to break, if anything, if I replace LoadFile with LoadFrom?

Even if it iss benign, it may be that I cannot do the replacement, just based on project schedules. If I cannot replace LoadFile with LoadFrom, is there a way to convince assemblies loaded with LoadFile to load dependencies? Is there a packaging trick I can use (embedded assembly, ILMerge, an AssemblyResolve event, something like that) that can allow an assembly loaded with LoadFile to also load its dependencies?

---

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.

http://blogs.msdn.com/b/suzcook/archive/2003/09/19/loadfile-vs-loadfrom.aspx

---

In addition to Madhur Ahuja's answer, note that in most cases it is actually Assembly.Load that you'd want to use.

http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57143.aspx