Application domains (or simply AppDomains) are logical subdivisions within a given process that host a set of related .NET Core assemblies. An AppDomain is further subdivided into contextual boundaries which are used to group like-minded .NET Core objects.

It is important to understand processes, AppDomains, and object contexts when working with numerous .NET Core APIs including multithreading, parallel processing, and object serialization.

A process is a running program, in simple terms. Formally speaking, a process is an operating system-level concept used to describe a set of resources and the necessary memory allocations used by a running application. For each .NET Core application loaded into memory, the OS creates a separate and isolated process for use during its lifetime. The process can be regarded as a fixed, safe boundary for a running application.

Every Windows process contains an initial "thread" that functions as the entry point for the application. A thread is a path of execution within a process. The first thread created by a process's entry point is termed the primary thread. The primary thread is created when the Main() method (or file with top level statements) is invoked.

Processes that contain a single primary thread of execution are intrinsically thread-safe. A single-thread could have the drawback of seeming unresponsive to the user if it were performing a complex operation.

The operating systems supported by .NET Core make it possible for the primary thread to spawn additional secondary threads, which are called worker threads, using a handful of API functions such as CreateThread(). Each thread becomes a unique path of execution in the process and has concurrent access to all shared points of data within the process.

Developers typically create additional threads to improve the program's overall responsiveness. But, using too many threads in a single process can potentially degrade performance, due to the CPU siwtching between the active threads which takes time.

On some machines, multithreading is most commonly an illusion provided by the OS. Machines that host a single, nonhyperthreaded CPU do not have the ability to literally handle multiple threads. The CPU will execute a thread for a unit of time called a time slice based in part on the thread's priority level. When the thread's time slice is up, the existing thread is suspended so that another thread can perform its business. To remember what was happening before it was kicked out of the way, each thread is given the ability to write to Thread Local Storage (TLS) and is provided with a separate call stack.

If you don't want to sweat the details, just remember that a thread is a unique path of execution within a Windows process. Every process has a primary thread and may contain additional threads that have been programmatically created.

The System.Diagnostics namespace defines several types that allow you to programmatically interact with processes and various diagnostic-related types such as the system event log and performance counters.

The System.Diagnostics.Process class allows you to analyze the processes running on a given machine (local or remote). Process also provides members to programmatically start and terminate processes, change the priority levels of threads, and obtain a list of active threads.

Process also defines a few useful methods:

static void ListAllRunningProcesses()
{
  // Get all processes on the local machine, ordered by PID
  var runningProcs =
    from proc
    in Process.GetProcesses(".")
    orderby proc.Id
    select proc;

  // Print out PID and name of each process
  foreach(var p in runningProcs)
  {
    string info = $"-> PID: {p.Id}\tName: {p.ProcessName}";
    Console.WriteLine(info);
  }
}

Process.GetProcesses() returns an array of Process objects that represent the running processes on the target machine. The dot notation here represents the local computer.

You can get a single process by its associated PID using Process.GetProcessById().

The set of threads is represented by the strongly typed ProcessThreadCollection collection, which contains some number of ProcessThread objects.

theProc = Process.GetProcessById(pID);
ProcessThreadCollection theThreads = theProc.Threads;

foreach(ProcessThread pt in theThreads)
{
  ...
}

Note that the ProcessThread type is not used to create, suspend, or kill threads in .NET. It is just for getting diagnostic information.

When talking about processes, a module is a general term used to describe a given *.dll (or the *.exe itself) that is hosted by a specific process. When you access the ProcessModuleCollection via the Process.Modules property, you can enumerate over all modules hosted within a process which can include traditional C-based libraries in addition to .NET Core-based.

The Start() and Kill() methods of the System.Diagnostics.Process class provide a way to programatically launch and terminate a process.

proc = Process.Start(@"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe", "www.facebook.com");

foreach (var p in Process.GetProcessesByName("MsEdge"))
{
  p.Kill(true);
}

The static Process.Start() method is overloaded, and at minimum, you need to specify the path and the filename of the process you want to launch. It returns a reference to the newly activated process which can be killed using the instance-level method Kill().

Process.Start() allows you to pass in a System.Diagnostics.ProcessStartInfo type that specifies additional information regarding how a process should come to life.

ProcessStartInfo can be used to take advantage of file associations.

Under the .NET and .NET Core platforms, executables are not hosted directly within a Windows process. Rather, .NET and .NET Core executables are hosted by a logical partition within a process called an application domain.

AppDomains are a key aspect of the OS-neutral nature of the .NET Core platform. This logical division abstracts away the differences in how the underlying OS represents the loaded executable.

AppDomains are also less expensive in terms of CPU and memory than a full-blown process.

AppDomains are fully and completely isolated from other AppDomains within a process. An application running in one AppDomain is unable to obtain data of any kind from another AppDomain, unless they use a distributed programming protocol.

In .NET Core, there is exactly one AppDomain. The ApplicationLoadContext provides assembly isolation in .NET Core.

The AppDomain is largely deprecated with .NET Core.

Your application has access to the default application domain using the static AppDomain.CurrentDomain property.

AppDomain defaultAD = AppDomain.CurrentDomain;

Assembly[] loadedAssemblies = defaultAD.GetAssemblies();

AppDomains are logical partitions used to host .NET Core assemblies. An application domain can be further subdivided into numerous load context boundaries. Conceptually, a load context creates a scope for loading, resolving, and potentially unloading a set of assemblies. In a nutshell, a .NET Core load context provides a way for a single AppDomain to establish a "specific home" for a given object.