Explicitly Unloading Assemblies: Unloading an AppDomain in VS .NET

Encoder Code39 in VS .NET Explicitly Unloading Assemblies: Unloading an AppDomain

The CLR doesn t support the ability to unload an assembly. Instead, you can unload an AppDomain, which causes all the assemblies contained within it to be unloaded. Unloading an AppDomain is very easy: you just call AppDomain s static Unload method, passing it a reference to the AppDomain you want unloaded. Note As I mentioned previously, assemblies that are loaded in a domain neutral fashion can never be unloaded from an AppDomain. To unload these assemblies, the process must be terminated. The AppDomainRunner sample application demonstrates how to create a new AppDomain, use a type in it, and then unload the AppDomain along with all its assemblies. The code also shows how to define a type that can be marshaled by reference across AppDomain boundaries. Finally, it shows what happens if you attempt to access a marshal by reference object that used to exist in an AppDomain that s been unloaded.

using System; using System.Reflection; using System.Threading; class App { static void Main() { // Create a new AppDomain. AppDomain ad = AppDomain.CreateDomain("MyNewAppDomain", null, null);

// Create a new MarshalByRef object in the new AppDomain. MarshalByRefType mbrt = (MarshalByRefType) ad.CreateInstanceAndUnwrap( Assembly.GetCallingAssembly().FullName, "MarshalByRefType"); // Call a method on this object. The proxy remotes // the call to the other AppDomain. mbrt.SomeMethod(Thread.GetDomain().FriendlyName); // I m done using the other AppDomain, so // I ll unload it and all its assemblies. AppDomain.Unload(ad); // Try to call a method on the other AppDomain s object. // The object was destroyed when the AppDomain was unloaded, // so an exception is thrown. try { mbrt.SomeMethod(Thread.GetDomain().FriendlyName); // The following line should NOT be displayed. Console.WriteLine( "Called SomeMethod on object in other AppDomain.\n" + "This shouldn t happen."); } catch (AppDomainUnloadedException) { // I ll catch the exception here, and the // following line should be displayed. Console.WriteLine( "Fail to call SomeMethod on object in other AppDomain.\n" + "This should happen."); } Console.ReadLine(); } }

// This type is derived from MarshalByRefObject. class MarshalByRefType : MarshalByRefObject { // This instance method can be called via a proxy. public void SomeMethod(String sourceAppDomain) { // Display the name of the calling AppDomain and my AppDomain. // NOTE: The application s thread has transitioned between AppDomains. Console.WriteLine( "Code from the {0} AppDomain\n" + "called into the {1} AppDomain.", sourceAppDomain, Thread.GetDomain().FriendlyName); } }

If you build and run this application, you ll see the following output:

Code from the AppDomainRunner.exe AppDomain called into the MyNewAppDomain AppDomain. Fail to call SomeMethod on object in other AppDomain. This should happen.

Reflection is most commonly used to learn about types or to manipulate objects using information that is typically known only at run time, not at compile time. Obviously, this dynamic exploring and manipulation of types and objects comes at a performance hit, so you should use it sparingly. In addition, a compiler can t help you locate and fix programming errors related to type safety when you re using reflection. The System.Type type is your starting point for doing type and object manipulations. System.Type is an abstract base type derived from System.Reflection.MemberInfo (because a Type can be a member of another type). The FCL provides a few types that are derived from System.Type: System.RuntimeType, System.Reflection.TypeDelegator, some types defined in the System.Reflection.Emit namespace, EnumBuilder, and TypeBuilder. Aside from the few classes in the FCL, Microsoft doesn t expect to define any other types that derive from Type. Note The TypeDelegator class allows code to dynamically subclass a Type by encapsulating the Type, allowing you to override some of the functionality while having the original Type handle most of the work. In general, the TypeDelegator type isn t useful. In fact, Microsoft isn t aware of anyone actually using the TypeDelegator type for anything.

Of all these types, the System.RuntimeType is by far the most interesting. RuntimeType is a type that is internal to the FCL, which means that you won t find it documented in the .NET Framework documentation. The first time a type is accessed in an AppDomain, the CLR constructs an instance of a RuntimeType and initializes the object s fields to reflect (pun intended) information about the type. Recall that System.Object defines a method named GetType. When you call this method, the CLR determines the specified object s type and returns a reference to its RuntimeType object. Because there is only one RuntimeType object per type in an AppDomain, you can use equality and inequality operators to see whether two objects are of the same type:

Boolean AreObjectsTheSameType(Object o1, Object o2) { return o1.GetType() == o2.GetType(); }

In addition to calling Object s GetType method, the FCL offers several more ways to obtain a Type object: The System.Type type offers several overloaded versions of a static GetType method. All versions of this method take a String. The string must specify the full name of the type (including its namespace), and compiler primitive types (such as C# s int, string, bool, and so on) aren t allowed. If the string is simply the name of a type, the method checks the calling assembly to see whether it defines a type of the specified name. If it does, a reference to the appropriate RuntimeType object is returned. If the calling assembly doesn t define the specified type, the types defined by MSCorLib.dll are checked. If a type with a matching name still can t be found, null is returned or a System.TypeLoadException exception is thrown, depending on which GetType method you call and what parameters you pass to it. The .NET Framework documentation fully explains this method.

You can pass an assembly qualified type string, such as System.Int32, mscorlib, Version=1.0.2411.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 , to GetType. In this case, GetType will look for the type in the specified assembly (loading the assembly if necessary). The System.Type type offers the following instance methods: GetNestedType and GetNestedTypes. The System.Reflection.Assembly type offers the following instance methods: GetType, GetTypes, and GetExportedTypes. The System.Reflection.Module type offers the following instance methods: GetType, GetTypes, and FindTypes. Many programming languages also offer an operator that allows you to obtain a Type object from a type name. When possible, you should use this operator to obtain a reference to a Type instead of using any of the methods in the preceding list because the operator generally produces faster code. In C#, the operator is called typeof. The following code demonstrates how to use it:

static void SomeMethod() { Type t = typeof(MyType); Console.WriteLine(t.ToString()); }

// Displays "MyType"

I compiled this code and obtained its IL code using ILDasm.exe. I ll explain what s going on in the annotated IL code here:

.method private hidebysig static void SomeMethod() cil managed { // Code size 23 (0x17) .maxstack 1 .locals ([0] class [mscorlib]System.Type t) // Look up the MyType metadata token, and place a "handle" to // the internal data structure on the stack. IL_0000: ldtoken MyType // Look up the RuntimeTypeHandle, and put a reference to // the corresponding RuntimeType object on the stack. IL_0005: call class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle( valuetype [mscorlib]System.RuntimeTypeHandle) // Save the RuntimeType reference in the local variable t. IL_000a: stloc.0 // Load the reference in t on the stack. IL_000b: ldloc.0 // Call the RuntimeType object s ToString method. IL_000c: callvirt instance string[mscorlib]System.Type::ToString() // Pass the String to Console.WriteLine. IL_0011: call void [mscorlib]System.Console::WriteLine(string) // Return from the method. IL_0016: ret } // End of method App::Foo

The ldtoken IL instruction has a metadata token specified as an operand. The ldtoken instruction causes the CLR to look for the internal data structure representing the specified metadata token. If an internal data structure for this metadata token doesn t exist, the CLR will create it on the fly. A 413

"handle" to this internal structure, represented as a System.RuntimeTypeHandle (a value type), is then pushed on the virtual stack. This "handle" is really the memory address of the internal data structure, but you should never access these internal structures directly. Now System.Type s static GetTypeFromHandle method is called. This method takes the "handle" and returns a reference to the RuntimeType object for the type. The rest of the IL code just saves the RuntimeTime reference in the variable t and then calls ToString on t; the resulting string is passed to Console.WriteLine and the method then returns. NoteThe ldtoken IL instruction allows you to specify a metadata token representing an entry in the type definition/reference table, the method definition/reference table, or the field definition/reference table. Keep in mind that C# s typeof operator accepts only the name of a type defined in the module or a type referenced in another module; you can t specify a field or method name. It s extremely rare that you d ever need to obtain a handle for a field or method, which is why most compilers won t offer operators that emit an ldtoken instruction that has a field or method metadata token. Field and method "handles" are most useful to compiler writers, not to application developers. If you re interested in field handles, however, see the System.RuntimeFieldHandle type and System.Reflection.FieldInfo s static GetFieldFromHandle method and instance Handle property. For method handles, see the System.RuntimeMethodHandle type and System.Reflection.MethodBase s static GetMethodFromHandle method and instance MethodHandle property. Once you have a reference to a Type object, you can query many of the type s properties to learn more about it. Most of the properties, such as IsPublic, IsSealed, IsAbstract, IsClass, IsValueType, and so on, indicate flags associated with the type. Other properties, such as Assembly, AssemblyQualifiedName, FullName, Module, and so on, return the name of the type s defining assembly or module and the full name of the type. You can also query the BaseType property to obtain the type s base type, and a slew of methods will give you even more information about the type. The .NET Framework documentation describes all the methods and properties that Type exposes. Be aware that there are a lot of them. For example, the Type type offers about 45 public instance properties. This doesn t even include the methods and fields that Type also defines. I ll be covering some of these methods in the next section. Note By the way, if you need to obtain a Type object that identifies a reference to a type, you can call one of the GetType methods, passing the name of the type suffixed with an ampersand, as demonstrated in the following code:

using System; using System.Reflection; class App { static void Main() { // Get the array of SomeMethod s parameters. ParameterInfo[] p = typeof(App).GetMethod("SomeMethod").GetParameters(); // Get a reference to a type that identifies a String reference. Type stringRefType = Type.GetType("System.String&"); // Is SomeMethod s first parameter a String reference Console.WriteLine(p[0].ParameterType == stringRefType);

// "True" } // You get identical results if ref is changed to out here: public void SomeMethod(ref String s) { s = null; } }