references an object defined in the C:\SomeTool\Component.dll assembly. What do you think should happen? Should the CLR realize that an assembly named Component.dll is already loaded in the AppDomain and just use this assembly? Or should the CLR realize that the C:\Component.dll assembly file was loaded "as a data file" and wouldn’t normally have been loaded into the AppDomain? The CLR can’t assume that the Component.dll file loaded from C:\ is the same Component.dll file that is in C:\SomeTool because the two assembly files can define completely different types and methods. You’ll be glad to hear that the CLR does the right thing here: it loads C:\SomeTool\Component.dll into the AppDomain, and the code in SomeTool.exe will access types and methods defined in the correct assembly. Here’s how this works. Internally, when Assembly’s LoadFrom method is called, the CLR opens the specified file and extracts the assembly’s version, culture, and public key token information from the file’s metadata. Then the CLR internally calls Load, passing all this information. Load applies all the policy information and searches for the assembly. If a matching assembly is found, the CLR compares the full pathname of the assembly file specified by LoadFrom with the full pathname of the assembly file found by Load. If the pathnames are the same, the assembly is considered to be a normal part of the application. If the pathnames are different or if Load doesn’t find a matching file, the assembly is considered a "data file" and isn’t considered a normal part of the application. When the CLR needs to find a dependency of an assembly loaded via LoadFrom, the CLR goes through the regular probing logic, and if it can’t find the dependant assembly in any of those locations, it looks in the directory where the referring assembly was found (and in any subdirectory whose name matches that of the dependant assembly). Earlier, I mentioned that you should always use Load and avoid using LoadFrom whenever possible. One reason is that LoadFrom is much slower than Load because it calls Load internally, which has to apply policy and scan several disk locations. Another reason is that an assembly loaded with LoadFrom is treated like a "data file," and if your AppDomain does load two identical assembly files from different paths, you’re wasting a lot of memory and also hurting run-time performance. Calling Load ensures that performance is as good as it can be and that an assembly isn’t loaded more than once into an AppDomain. Whenever you’re about to place a call to LoadFrom, think about your application and try to figure out a way to change it so that Load will work instead. Of course, there will be times when Load simply won’t do and using LoadFrom is necessary (such as in the SomeTool.exe example). Certainly, if you can’t use Load, use LoadFrom instead—just be careful.
Building a Hierarchy of Exception-Derived Types The ExceptionTree sample application (source code shown below) displays all classes that are ultimately derived from System.Exception. However, I wanted to examine types in several assemblies to produce this tree. To accomplish this, the application must explicitly load all the assemblies whose types I want to consider. This is the job of the application’s LoadAssemblies method. After loading all the assemblies, the application gets an array of all the AppDomain’s assemblies. Then I get an array for all types defined in each assembly. For each type, I check its base type by querying Type’s BaseType property. If the Type returned is System.Exception, this type is an exception type. If the Type returned is System.Object, the type isn’t an exception type. If the Type returned isn’t either of these types, I check the base type’s type recursively until I find Exception or Object.