Assembly.Load() takes an assembly display name as input, while Assembly.LoadFrom() takes a file path as input.
Typically the application will only call one of them, but not one after the other.
I have seen a few cases where people want to do an Assembly.Load(). If that fails they will re-try with Assembly.LoadFrom().
The usual case is that the application gets the input from somewhere, could be user input, or a string from database etc. But the application has no idea whether the input is a display name or a file path. So it does the fall back thing.
A design that can not distinguish a display name from a file path does not sound like a good design to me. But understood that sometimes there is no choice.
But you still have several different ways to do the fallback.
- call File.Exists() on the input. If that succeeds, assume it is a file and call Assembly.LoadFrom(). Otherwise, assume it is a display name and call Assembly.Load().
- call Assembly.Load(), if that fails, try Assembly.LoadFrom().
- call Assembly.Load(), and hook up AssemblyResolveEvent to fallback to Assembly.LoadFrom()
- call Assembly.LoadFrom(), if that fails, try Assembly.Load().
Personally I favor 1). But if the input is a URL then you can’t use 1).
2) and 3) have subtle differences.
In 2) you have to catch an exception returned from Assembly.LoadFrom(). In 3) you may not need.
On the other hand, 3) will affect every other unrelated Assembly.Load(). More importantly, the display name you get in the ResolveEventArgs is not the original one. It has been processed by fusion, which may or may not be the same as the original one.
That is, I definitely prefer 2) over 3).