Free mag vol1 | Page 701

CHAPTER 17  PROCESSES, APPDOMAINS, AND OBJECT CONTEXTS This time, the output of the program would appear as so (note the presence of CarLibrary.dll): ***** Fun with Custom AppDomains ***** ***** Here are the assemblies loaded in CustomAppDomains.exe ***** -> Name: CustomAppDomains -> Version: 1.0.0.0 -> Name: mscorlib -> Version: 4.0.0.0 -> Name: System -> Version: 4.0.0.0 -> Name: System.Core -> Version: 4.0.0.0 ***** Here are the assemblies loaded in SecondAppDomain ***** -> Name: CarLibrary -> Version: 2.0.0.0 -> Name: mscorlib -> Version: 4.0.0.0  Note Remember, if you debug this application, you will see many additional libraries loaded into each application domain. Programmatically Unloading AppDomains It is important to point out that the CLR does not permit unloading individual .NET assemblies. However, using the AppDomain.Unload() method, you are able to selectively unload a given application domain from its hosting process. When you do so, the application domain will unload each assembly in turn. Recall that the AppDomain type defines the DomainUnload event, which is fired when a custom application domain is unloaded from the containing process. Another event of interest is the ProcessExit event, which is fired when the default application domain is unloaded from the process (which obviously entails the termination of the process itself). If you want to programmatically unload newAD from the hosting process, and be notified when the associated application domain is torn down, you could update MakeNewAppDomain() with the following additional logic: private static void MakeNewAppDomain() { // Make a new AppDomain in the current process. AppDomain newAD = AppDomain.CreateDomain("SecondAppDomain"); 644