Why does MSDN say it's "rare" to load an assembly by path?

Question

According to the documentation for System.Assembly:

The LoadFile and LoadFrom methods are provided for rare scenarios in which an assembly must be identified by path.

They suggest that you would more commonly load an assembly by its display name (for example, "System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089").

This doesn't make any sense to me. If you wanted to reference an assembly by its version and public key, you would add a reference at compile time; you wouldn't be loading it at runtime using the Assembly class. The typical scenario for loading an assembly at runtime is when you're loading a plug-in, which would be done by path -- since you're either scanning a directory for plug-ins, or reading some kind of manifest that says where they're located.

Why do the docs say that, among scenarios where you're dynamically loading an assembly, loading it by path is "rare"? As far as I can tell, it's loading it by display name that would be rare.

Answer 1

I believe what they are saying is that if you specify a path, it will load from that path, but they would prefer you tell it "what" you want to load, and let .net runtime load it from where it is 'supposed' to be be, based on its rules.

http://msdn.microsoft.com/en-us/library/yx7xezcf%28VS.71%29.aspx

Answer 2

Well, it ought to be rare since it is so troublesome. But yes, plug-ins tend to be loaded by LoadFrom(). Never by LoadFile(), that's asking for real trouble.

The trouble is that you cannot really predict what's going to happen with the assemblies that the plug-in depends on. Getting those resolved properly is a crapshoot. The solution you should favor is a .config file so that you can use Load() and probing paths are predictable.

Answer 3

I've loaded "plugins" by display name. Why? Well, because believe or not, assemblies don't need to live on a disk at all (or at least not in a way that gives you a direct path to them). This can be incredibly useful.

Additionally, "optional" assemblies such as serialization assemblies are usually Assembly.Loaded by name.