Assembly.LoadFrom

Assembly.LoadFrom is a weirdo.

1. It is order dependent. If you call Assembly.LoadFrom on multiple assemblies with the same assembly name, you will always get the first copy, even though those assemblies have different file paths.
2. Assemblies loaded by Assembly.LoadFrom cannot be seen by assemblies in the default load context. If you want the assembly to be seen in the default load context, you have to load it in the default load context, or return it through AssemblyResolve event.
3. Assembly returned from Assembly.LoadFrom may end up in default load conext, or LoadFrom load context, depending on whether the same file can be found in default load context or not.
4. Dependencies of Assembly.LoadFrom may be satisfied from application base, or the assemblies’s directory
5. Why are there different load contexts at all?

But if it is so confusing, why have it in the first place?

It was designed to enable the add-in scenario. You can imagine that an add-in will live in a different directory than the host, and all the dependencies of the add-in live alongside the add-in. LoadFrom solves the problem of loading the add-in, and its dependencies.

This is particularly useful for COM Interop (thinking unmanaged host with managed add-ins). On majority cases the managed add-ins do not reside in the application’s directory. You either put the add-ins into GAC, or you have to use Assembly.LoadFrom.

But the model is difficult to extend to multiple add-ins scenario. The problems include but not limited to 1. How to manage dependencies of those add-ins. 2. How do those add-ins communicate to each other.

Over the years people realize Add-in is a complex problem, and can’t be solved alone with LoadFrom (This is almost clear right after we shipped .Net framework v1.0). Right people is thinking about this problem. You may see a proposal in future version of .Net framework.

Given the greatest confusion it brings to people, and the inability to solve the add-in problem, maybe, in the future you will see Assembly.LoadFrom being deprecated.