Customizing the Microsoft .NET Framework Common Language Runtime

The dynamic nature of extensible applications makes loading assemblies more complicated than for applications in which all dependencies are statically referenced when the application is compiled. There are two reasons for this. First, the add-in assemblies that are added to the application must be loaded in a late-bound fashion. Loading assemblies on the fly like this requires the use of a set of methods in the .NET Framework called the assembly loading APIs. These APIs let you reference an assembly by providing either its name or the name of the file on disk that contains the assembly's manifest. When using the assembly loading APIs, take care to make sure you are calling them from the application domain in which you'd like the assembly to be loaded. Otherwise, you often end up loading an assembly into an application domain that you didn't intend to. The fuslogvw.exe utility from the .NET Framework SDK is a great tool not only to track down assembly loading failures, but also to understand how the process of loading assemblies works in general.

The other reason that loading assemblies in extensible applications can get complicated is the need to understand how assemblies built with different versions of the CLR interact in the same process. As the author of the extensible application, you get to decide which version of the CLR is loaded in your process. Given that, the CLR will automatically make sure that the versions of the .NET Framework assemblies that are loaded are the ones that were built and tested along with the CLR running in the process. If, for some reason, this default behavior doesn't work in your scenario, you can always override it using a configuration file associated with your application domain.