Introduction

An application domain, usually called an AppDomain, is a .NET runtime isolation boundary inside a process. In classic .NET Framework it was an important way to separate loaded code, configuration, and some failure handling without creating a whole new operating-system process.

What an AppDomain Does

A process is the operating-system boundary. An AppDomain is a CLR boundary inside that process.

Historically, AppDomains were used to:

• isolate assemblies loaded by different components
• unload groups of assemblies together
• run plugins with some separation from the host
• keep faults from crashing unrelated managed code as easily
• apply different configuration or probing behavior

You can think of it as "lighter than a process, heavier than a normal object boundary."

Why AppDomains Existed

In .NET Framework, assemblies loaded into the default AppDomain could not be unloaded individually. If you wanted to load plugin code, execute it, and later unload it, the usual solution was to create a separate AppDomain and tear that whole domain down when you were done.

A simplified .NET Framework-style example:

1using System;
2
3class Program
4{
5    static void Main()
6    {
7        AppDomain domain = AppDomain.CreateDomain("PluginDomain");
8        Console.WriteLine(domain.FriendlyName);
9        AppDomain.Unload(domain);
10    }
11}

This was attractive for plugin hosts, test runners, and ASP.NET-style application isolation.

The Important Modern Caveat

If you are using modern .NET, meaning .NET Core, .NET 5, .NET 6, and later, AppDomains are much less central. Microsoft documentation is clear that creating and unloading multiple AppDomains is a .NET Framework-era concept. Modern .NET has a single AppDomain per process for most practical purposes, and AssemblyLoadContext is the modern mechanism for dynamic assembly loading and unloading.

That means older explanations are only partly correct today. They describe the historical role of AppDomains, but not the recommended design for current .NET applications.

AppDomain in .NET Framework vs Modern .NET

In .NET Framework:

• multiple AppDomains per process were a real design tool
• unloading an AppDomain unloaded the assemblies inside it
• remoting and cross-domain calls were common in some systems

In modern .NET:

• multiple unloadable AppDomains are not the normal model
• process isolation or AssemblyLoadContext is preferred
• many old AppDomain-related APIs exist mainly for compatibility

So when someone asks "What is an AppDomain?" the honest answer depends on which runtime they mean.

AppDomain Data and Introspection

Even in modern .NET, AppDomain.CurrentDomain still exists and is useful for process-level runtime information:

1using System;
2
3class Program
4{
5    static void Main()
6    {
7        AppDomain domain = AppDomain.CurrentDomain;
8        Console.WriteLine(domain.FriendlyName);
9        Console.WriteLine(domain.BaseDirectory);
10    }
11}

This is common for diagnostics and environment discovery. It does not mean you should build a new isolation architecture around AppDomains in modern runtimes.

The Modern Replacement: AssemblyLoadContext

If the real need is dynamic plugin loading and unloading in current .NET, use AssemblyLoadContext instead of AppDomain-based patterns.

Example:

1using System.Reflection;
2using System.Runtime.Loader;
3
4class PluginLoadContext : AssemblyLoadContext
5{
6    public PluginLoadContext() : base(isCollectible: true) { }
7}
8
9class Program
10{
11    static void Main()
12    {
13        var context = new PluginLoadContext();
14        Assembly assembly = context.LoadFromAssemblyPath("/path/to/MyPlugin.dll");
15
16        Console.WriteLine(assembly.FullName);
17
18        context.Unload();
19    }
20}

This is the modern answer to many problems that older articles solved with AppDomains.

When AppDomains Still Matter Conceptually

Even if you do not create custom AppDomains anymore, the concept still helps explain:

• why AppDomain.CurrentDomain exists
• how older ASP.NET and .NET Framework hosts isolated applications
• why some legacy plugin systems look the way they do
• why some APIs are marked as framework-specific or compatibility-oriented

So AppDomains are still worth understanding, especially when maintaining legacy code.

Common Pitfalls

• Assuming AppDomains are still the recommended isolation mechanism in modern .NET.
• Reading .NET Framework examples and applying them unchanged to .NET 6 or .NET 8 code.
• Confusing process isolation with AppDomain isolation; they are not the same thing.
• Expecting to unload a single assembly directly in .NET Framework when the real unload unit was the AppDomain.
• Using AppDomain concepts for new plugin systems when AssemblyLoadContext is the better fit.

Summary

• An AppDomain is a CLR isolation boundary inside a process.
• It was very important in classic .NET Framework for loading and unloading code safely.
• In modern .NET, AppDomains are mostly a compatibility concept rather than the main extensibility tool.
• 'AppDomain.CurrentDomain is still useful for runtime information.'
• For new plugin-loading designs, prefer AssemblyLoadContext over AppDomain-based patterns.