Assembly.LoadFrom demystified

Posts: 69
Comments: 233
Trackbacks: 162

<< Extend the Enterprise Library Config Tool - A Configurable Assembly Loader | Home | Store your App.Config inside SQL Server >>

Assembly.LoadFrom demystified

Rules are meant to be bro.. ahem expanded. Especially if everybody tells you not to do so ;-). The Assembly Loader Rules are for example a very strict set of rules. One rule of the loader is that you cannot load assemblies from directories above the directory where the executable is located. This can cause some headaches if you want to share some assemblies across applications which are not installed inside the GAC. You can bypass this restriction by using Assembly.LoadFrom. A very good article about the how and when of Assembly.LoadFrom can be found at GotDotNet. If you have to deal with plugin architectures and loosely coupled components you will soon end up in a situation where you need to expand the default assembly loader rules. You can configure the loader to some extent via your App.Config file but you cannot configure a probing path for directories above your application binary location. Lets suppose you have an application lets call it App.exe which references ClassLibrary1.Dll which in turn references ClassLibrary2.dll. Now you have to call Assembly.LoadFrom for ClassLibrary1.dll for some reason (e.g. it is a configured plugin). I have drawn the dependencies in the diagram below