Assembly.Load vs LoadFile vs LoadFrom

When to use LoadFrom:

LoadFrom is very useful when writing an application that dynamically load portions of itself or user plug-ins written to extend the application. For example, a popular application model that has evolved with .NET is that of a Windows Forms application that installs itself as a small shell on the desktop, then dynamically loads its pieces on demand from a web server given a path name. These applications sometimes also support a mechanism where a user can extend the application by giving a path name to the assembly that implements the extension.

 

Method	Advantages	Disadvantages
Load	Gets the benefits of versioning and policy. Best avoids "Dll Hell." Dll Hell can break your app over time. Dependencies available in the Load context are automatically found.	Dependencies in other contexts are not available unless you subscribe to the AppDomain.AssemblyResolve event.
LoadFrom	Assemblies can be loaded from multiple paths, not just from beneath the ApplicationBase. Dependencies already loaded in this context will automatically be found. Dependencies in the same dir as the requesting LoadFrom context assembly will automatically be found.	If a Load context assembly tries to load this assembly by display name, it will fail to be found, by default (e.g., when mscorlib.dll deserializes this assembly). Worse, an assembly with the same identity, but at a different path, could be found on the probing path, causing an InvalidCastException, MissingMethodException, or unexpected method behavior, later on. If an assembly by the same identity is already loaded, you’ll get that one back, even if you’ve specified a path to a different one. It does a FileIOPermission.Read + PathDiscovery demand, or a WebPermission demand, on the path/URL specified. Ngen image won’t be used, and can’t be loaded as domain-neutral. v1.0 and v1.1 CLR only: Won’t be affected by policy, so can’t be centrally serviced.
Neither	Avoids probing costs for loading this assembly. You can load multiple assemblies with the same identity into the same appdomain. You get the bits from the location you specified (as opposed to LoadFrom), except starting in v2, policy/GAC overrides it.	Nothing can bind to this assembly unless you’ve subscribed to the AssemblyResolve event. Dependencies can only be loaded from the Load context or using the AssemblyResolve event. Passing this assembly to another AppDomain may become tricky (e.g., when this is a Reflection Emit assembly that hasn’t been saved). Ngen image won’t be used, and can’t be loaded as domain-neutral. v1.0 and v1.1 CLR only: Won’t be affected by policy, so can’t be centrally serviced.

Compiled from:
http://www.gotdotnet.com/team/clr/LoadFromIsolation.aspx
http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx
http://blogs.msdn.com/suzcook/archive/2003/09/19/57248.aspx
http://blogs.msdn.com/suzcook/archive/2003/06/13/57180.aspx