The SLAR (vol2) on System.AppDomain


Continuing in the series sharing some of the information in the .NET Framework Standard Library Annotated Reference Vol 1 and .NET Framework Standard Library Annotated Reference Vol 2 with some information on AppDomain.


 


BA


We introduced Application Domains as a lightweight process mechanism. Because managed


code can be verifiably type safe (memory safe) we did not need the heavyweight address space


barrier that processes provide. This savings works out well most of the time. However, when


using interop with unmanaged code it does cause some problems when type safety is violated.


One notable example of this is the loader-lock and AppDomain marshaling problem that C++


was susceptible to. We fixed this problem in a service pack of v1.1.


 


AN


AppDomain is one of the few classes in the .NET Framework that is commonly used via COM


Interop (often for CLR hosting scenarios), so we made a point of exposing most of its


functionality via an interface called _AppDomain. Exposing a real managed interface to COM


consumers is much better than taking advantage of our regrettable “class interface”


functionality, since we avoid a host of versioning problems by being in complete control of


what gets exposed. The unfortunate thing about _AppDomain (besides the non-standard name,


which I know drives folks like Brad crazy) is that the overloaded members are still just as


clunky to use from COM. For example, the Load overloads are exposed as Load, Load_2,


Load_3, and so on. But because of the versioning benefits, expect more of our COM-visible


classes in the .NET Framework to start implementing real interfaces like _AppDomain and stop


exposing class interfaces in the future.


 


using System;


public class AppDomainSample


{


public static void Main()


{


AppDomain domain = AppDomain.CreateDomain(“MyNewDomain”);


domain.AssemblyLoad +=


new AssemblyLoadEventHandler(MyLoadHandler);


Console.WriteLine(“FriendlyName is ‘{0}'”, domain.FriendlyName);


Console.WriteLine(“Attempting to execute HelloWorld.exe…”);


domain.ExecuteAssembly(“HelloWorld.exe”);


Console.WriteLine(“Finished executing HelloWorld.exe.”);


AppDomain.Unload(domain);


Console.WriteLine(“AppDomain unloaded.”);


Console.WriteLine();


Console.WriteLine();


Console.WriteLine(“Press Enter to continue”);


Console.ReadLine();


}


public static void MyLoadHandler(object sender,


AssemblyLoadEventArgs args)


{


Console.WriteLine(“Loaded assembly {0}”,


args.LoadedAssembly.FullName);


}


}


The output is


FriendlyName is ‘MyNewDomain’


Attempting to execute HelloWorld.exe…


Loaded assembly HelloWorld, Version=1.0.1767.19756, Culture=neutral, PublicKeyTo


ken=null


Loaded assembly System.Windows.Forms, Version=1.0.5000.0, Culture=neutral, Publi


cKeyToken=b77a5c561934e089


Loaded assembly System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a


5c561934e089


Loaded assembly System.Drawing, Version=1.0.5000.0, Culture=neutral, PublicKeyTo


ken=b03f5f7f11d50a3a


Loaded assembly System.Xml, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=


b77a5c561934e089


Finished executing HelloWorld.exe.


AppDomain unloaded.


Press Enter to continue

Comments (0)