Customizing the Microsoft .NET Framework Common Language Runtime

You've seen how application domains can be used to isolate groups of assemblies within a process and have taken a look at the techniques available to customize domains for various scenarios. In this chapter, I discuss what's involved in loading assemblies into the application domains you create as part of your extensible application. Much has been written in various books, magazines, and product documentation about the general topic of assembly loading. Rather than repeating it, I focus on those aspects of assembly loading that are of specific interest to writers of extensible applications.

By their nature, extensible applications don't have upfront knowledge of which assemblies will be loaded while the application is running. Instead, the set of add-ins to be loaded is typically specified either interactively by the end user or through some sort of dynamic configuration system. For example, the user of a productivity application can have the option to choose an add-in to run using a menu command. Similarly, a Microsoft SQL Server administrator has the option of adding new assemblies to a database at any time. In addition, it's often the case that the assemblies loaded into an extensible application are written by a variety of different vendors.

The dynamic nature of extensible applications makes assembly loading more complicated for two primary reasons. First, assemblies are typically loaded in a late-bound fashion. In more static applications, the majority of assembly references are recorded in an application's metadata when the application is compiled. The CLR reads these references as the application is running and follows a well-defined set of rules for locating and loading the assembly. In contrast, the add-in assemblies in extensible applications are loaded using a variety of APIs, some of which are managed and some of which are unmanaged. Not only can you use numerous APIs, you can use different basic techniques to identify the assembly you'd like to load. You can specify a reference to an assembly dynamically either by supplying the assembly's identity (or even just part of its identity) or by providing the fully qualified name of a disk file that contains the assembly's manifest. The second reason that assembly loading is more complicated in dynamic applications is CLR and Microsoft .NET Framework versioning. Because the origin of the assemblies you'll load into an extensible application varies, there's a good chance that not all assemblies will be built using the same version of the CLR and the .NET Framework. As times goes on and the number of publicly available versions of the .NET Framework increases, it will become more and more likely that you'll load assemblies with varying version dependencies into the same process. Understanding the implications of loading assemblies built with different versions of the .NET Framework is necessary not only to ensure that add-ins work predictably, but also to ensure that the stability of your overall application isn't compromised.