19.12 Loading an Assembly into a New Application Domain

You want to load an assembly but at the same time confine the assembly to some application domain other than the one currently executing.

Technique

The Assembly class is not remotable. In general, it is not possible to manipulate an assembly in a remote application domain. Loading an assembly with some method such as Assembly.Load() generally loads that assembly into the domain that is currently executing. If you want an assembly loaded into a new application domain, you need to explicitly create that domain and then have that domain itself execute the code that loads the assembly.

Listing 19.2 illustrates a Main() method that loads an assembly with the path specified by the first argument so you can examine that assembly's fully qualified name .

Listing 19.2 Main() Method That Loads Another Assembly

 static void Main(string[] args) {     Console.WriteLine(AppDomain.CurrentDomain.FriendlyName + ":  " + args[0]);     Assembly assembly = Assembly.LoadFrom(args[0]);     Console.WriteLine(assembly.FullName); } 

This code loads the assembly onto the current application domain. To execute this code in a separate domain, let's assume the assembly containing this code is stored in the file C:\CookbookSamples\AssemblyLoader.exe . Listing 19.3 shows how you would execute Listing 19.2 in a new application domain to examine System.Windows.Forms.dll .

Listing 19.3 Executing Code in a New Application Domain

 string path =     @"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.Windows.Forms.dll"; AppDomain childDomain = AppDomain.CreateDomain("child domain"); childDomain.ExecuteAssembly(@"C:\CookbookSamples\AssemblyLoader.exe ",      null, new string[]{path} ); AppDomain.Unload(childDomain); 

This code shows three steps:

1. You create the new application domain using the static AppDomain.CreateDomain() method. The string passed to AppDomain.CreateDomain() is the user -friendly name of the new application domain and has no significance here.

2. You execute the AssemblyLoader.exe assembly in the new domain by calling AppDomain.ExecuteAssembly() . Note that no new thread is created here: When AppDomain.ExecuteAssembly() is invoked, the current thread simply swaps domains into the specified application domain and starts executing the given assembly, just as if you'd just started running that assembly as a new process. Once execution finishes, the thread reverts to the current application domain. The overload of AppDomain.ExecuteAssembly() used here takes three parameters: the path of the assembly to be executed, any evidence used to set security for the new assembly (you are not using this parameter here so you pass null ), and a string[] array containing the arguments to be passed to the entry method of the new assembly.

3. Finally, you unload the new application domain. This step removes the application domain from memory and also removes from memory any assemblies that were loaded into that application domain (provided those assemblies are not also being used by another application domain).

Comments

One reason for loading an assembly into a separate application domain is to allow for unloading: The CLR does not at present supply any means to unload an individual assembly, but it is possible to unload an application domain. This step might be important, for example, if your application needs to load a large number of assembliesperhaps to examine information about those assemblies. Once it does so, it no longer needs each assembly. If those assemblies remain loaded, it could impact performance by increasing the application's virtual-memory requirements.