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.
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.
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