Working with the AppDomain Class in .NET

Q: When should I create a new application domain instead of using the default domain?

Create new application domains when you need to isolate code for security reasons, when you want the ability to unload assemblies without restarting the process, when you need different configuration settings for different parts of your application, or when you want to prevent failures in one component from affecting others. The default domain cannot be unloaded and exists for the lifetime of the process.

Q: What's the performance impact of using multiple application domains?

Creating application domains has minimal overhead compared to creating separate processes, but cross-domain calls are slower than in-domain calls due to marshaling. Use multiple domains when you need isolation but want better performance than separate processes; for CPU-bound tasks without isolation needs, the default domain is fine. For long-running services that must unload components, the ability to free resources without restarting often outweighs the marshaling overhead.

Q: How do I configure security policies for an application domain?

Use Evidence and PermissionSet to define security policies. You can restrict assemblies to specific zones (e.g., Internet) and grant only necessary permissions such as execution and limited file I/O, creating a sandboxed environment. Pass Evidence and PermissionSet during domain creation or when executing assemblies to enforce these constraints.

Last Updated: Oct 31, 2025

6 min read

Legacy Archive

Introduction

The .NET framework implements all Application Domain functionality in the System.AppDomain class. This class lets you create and terminate application domains, load and unload assemblies, enumerate assemblies and threads within a domain, and more. You can create instances of types from assemblies, execute assemblies, define security privileges, and manage domain-specific data. The AppDomain class is sealed and cannot be inherited.

Core Functionality and Events

AppDomain exposes events you can handle for key lifecycle moments, including assembly loading/unloading, unhandled exceptions, and domain shutdown notifications.

Working with Application Domains

Here's the typical workflow when using Application Domains:

Creating an Application Domain

Since AppDomain has no public constructor, create instances using CreateDomain:

Creating an AppDomain

AppDomain newDomain = AppDomain.CreateDomain("MyDomain");
Console.WriteLine("Domain Name: " + newDomain.FriendlyName);

Loading and Executing Assemblies

Load the required assembly into the domain and execute it:

Loading Assemblies

string assemblyPath = @"C:\MyApp\MyAssembly.dll";
newDomain.Load("MyAssembly");

// Execute an assembly with a Main entry point
newDomain.ExecuteAssembly(assemblyPath);

Unloading an Application Domain

Unload when finished to free resources:

Unloading a Domain

AppDomain.Unload(newDomain);

Configuring Application Domains

Configure domains to create customized execution environments—useful for restricting assemblies with limited privileges and reducing security risks. Beyond isolation, configuration helps prevent malicious code from damaging your system.

Using AppDomainSetup

Configure a domain during creation via AppDomainSetup:

Configuring with AppDomainSetup

AppDomainSetup setup = new AppDomainSetup();
setup.ApplicationBase = @"C:\MyApp";
setup.ConfigurationFile = "MyApp.config";
setup.ApplicationName = "MyApplication";
setup.PrivateBinPath = "bin;lib";

AppDomain customDomain = AppDomain.CreateDomain(
    "CustomDomain", 
    null, 
    setup
);

Key properties include ApplicationBase, ConfigurationFile, ApplicationName, and PrivateBinPath. Changes apply to newly created domains only.

Implementing Security with Evidence

Use System.Security.Policy.Evidence to influence permissions granted to code:

Evidence-Based Security

using System.Security;
using System.Security.Policy;
using System.Security.Permissions;

Evidence evidence = new Evidence();
evidence.AddHostEvidence(new Zone(SecurityZone.Internet));

AppDomain restrictedDomain = AppDomain.CreateDomain(
    "RestrictedDomain",
    evidence
);

Evidence can include origin, signatures, and publisher info. Typically, the Internet zone maps to highly restrictive permissions.

Complete Security Configuration Example

Create a sandboxed domain with restricted permissions:

Sandboxed Domain

PermissionSet permissions = new PermissionSet(PermissionState.None);
permissions.AddPermission(
    new SecurityPermission(SecurityPermissionFlag.Execution)
);
permissions.AddPermission(
    new FileIOPermission(FileIOPermissionAccess.Read, @"C:\SafeFolder")
);

AppDomainSetup setup = new AppDomainSetup();
setup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory;

AppDomain sandboxDomain = AppDomain.CreateDomain(
    "SandboxDomain",
    null,
    setup,
    permissions
);

Benefits of Application Domains

Security Benefits

Restrict each assembly's access using code-access and role-based security. For example, set principal policy:

Setting Principal Policy

AppDomain currentDomain = AppDomain.CurrentDomain;
currentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);

Reliability Improvements

Isolate core tasks that must not terminate, or risky tasks that could fail:

Reliable Domain

AppDomain reliableDomain = AppDomain.CreateDomain("CoreServices");
// Load critical assemblies here

Efficiency Gains

Unload assemblies by loading them into a temporary domain:

Temporary Domain Usage

AppDomain tempDomain = AppDomain.CreateDomain("TemporaryDomain");
tempDomain.Load("LargeDLL");

// Use the assembly
// ... perform operations ...

// Unload when finished
AppDomain.Unload(tempDomain);

Monitoring Application Domains

Inspect domain settings and loaded assemblies:

Monitoring Domains

AppDomain domain = AppDomain.CurrentDomain;

Console.WriteLine("Base Directory: " + domain.BaseDirectory);
Console.WriteLine("Friendly Name: " + domain.FriendlyName);
Console.WriteLine("Shadow Copy: " + domain.ShadowCopyFiles);

// Get all loaded assemblies
foreach (Assembly assembly in domain.GetAssemblies())
{
    Console.WriteLine("Loaded: " + assembly.FullName);
}

Conclusion

Application domains provide isolation, security, and resource management that make .NET apps more robust. Mastering AppDomain enables reliable and efficient applications with fine-grained control over assembly loading, execution, and cleanup.

Quick FAQ

When should I create a new application domain instead of using the default domain?

Create new application domains for isolation, the ability to unload assemblies without restarting, different configuration needs, or to prevent failures in one component from affecting others. The default domain cannot be unloaded and lives for the process lifetime.

What's the performance impact of using multiple application domains?

Domains are lighter than separate processes, but cross-domain calls incur marshaling overhead. Use multiple domains when you need isolation; for CPU-bound code without isolation requirements, stay in the default domain. For long-running services that must unload components, the unload capability often outweighs the overhead.

How do I configure security policies for an application domain?

Use Evidence and PermissionSet to sandbox code. Restrict to zones like Internet and grant only essential permissions (e.g., execution, limited file I/O). Supply these during domain creation or when executing assemblies to enforce the policy.

Back to Articles