Home > .NET Framework > Assembly.Load vs LoadFile vs LoadFrom

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

Categories: .NET Framework
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: