Using Application Domains (C#)

Application domains, which are represented by AppDomain objects, help provide isolation, unloading, and security boundaries for executing managed code. You use application domains to isolate tasks that might bring down a process. If the state of the AppDomain that’s executing a task becomes unstable, the AppDomain can be unloaded without affecting the process. This is important when a process must run for long periods without restarting. You can also use application domains to isolate tasks that should not share data. If an assembly is loaded into the default application domain, it cannot be unloaded from memory while the process is running. However, if you open a second application domain to load and execute the assembly, the assembly is unloaded when that application domain is unloaded. Use this technique to minimize the working set of long-running processes that occasionally use large DLLs.
using System;
using System.Reflection;
using System.Threading;
class Module1
    public static void Main()
        // Get and display the friendly name of the default AppDomain.
        string callingDomainName = Thread.GetDomain().FriendlyName;
        // Get and display the full name of the EXE assembly.
        string exeAssembly = Assembly.GetEntryAssembly().FullName;
        // Construct and initialize settings for a second AppDomain.
        AppDomainSetup ads = new AppDomainSetup();
        ads.ApplicationBase =
        ads.DisallowBindingRedirects = false;
        ads.DisallowCodeDownload = true;
        ads.ConfigurationFile =
        // Create the second AppDomain.
        AppDomain ad2 = AppDomain.CreateDomain("AD #2", null, ads);
        // Create an instance of MarshalbyRefType in the second AppDomain.
        // A proxy to the object is returned.
        MarshalByRefType mbrt =
            (MarshalByRefType) ad2.CreateInstanceAndUnwrap(
        // Call a method on the object via the proxy, passing the
        // default AppDomain’s friendly name in as a parameter.
        // Unload the second AppDomain. This deletes its object and
        // invalidates the proxy object.
            // Call the method again. Note that this time it fails
            // because the second AppDomain was unloaded.
            Console.WriteLine("Sucessful call.");
            Console.WriteLine("Failed call; this is expected.");
// Because this class is derived from MarshalByRefObject, a proxy
// to a MarshalByRefType object can be returned across an AppDomain
// boundary.
public class MarshalByRefType : MarshalByRefObject
    //  Call this method via a proxy.
    public void SomeMethod(string callingDomainName)
        // Get this AppDomain’s settings and display some of them.
        AppDomainSetup ads = AppDomain.CurrentDomain.SetupInformation;
        Console.WriteLine("AppName={0}, AppBase={1}, ConfigFile={2}",
        // Display the name of the calling AppDomain and the name
        // of the second domain.
        // NOTE: The application’s thread has transitioned between
        // AppDomains.
        Console.WriteLine("Calling from ‘{0}’ to ‘{1}’.",
/* This code produces output similar to the following:
AppDomainX, Version=, Culture=neutral, PublicKeyToken=null
AppName=, AppBase=C:\AppDomain\bin, ConfigFile=C:\AppDomain\bin\AppDomainX.exe.config
Calling from ‘AppDomainX.exe’ to ‘AD #2’.
Failed call; this is expected.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: