52

What is the difference between AppDomain, Assembly, Process, and a Thread?

Frederik Struck-Schøning
  • 12,981
  • 8
  • 59
  • 68
tush1r
  • 19,443
  • 14
  • 36
  • 35

2 Answers2

66

An AppDomain is an isolation unit within a process. AppDomains can be created at runtime, loaded with code, and unloaded. Its an isolation boundary designed to make .NET apps more reliable.

An assembly holds one or more modules, which hold compiled chunks of code. You will typically see an assembly as an .EXE or a .DLL.

A process is an executing application (waaaay oversimplified).

A thread is an execution context. The operating system executes code within a thread. The operating system switches between threads, allowing each to execute in turn, thus giving the impression that multiple applications are running at the same time.

To put it all together (very simplified)...

A program is executed. A process is created by the operating system, and within its single thread it starts loading code to execute. In a .NET application, a single AppDomain is created by the CLR. The application's executing assembly (the .EXE) is loaded into this AppDomain and begins execution. The application can spawn new processes, create AppDomains, load other assemblies into these domains, and then create new Threads to execute code in any of these AppDomains.

  • 3
    Technically, an assembly is a component, comprised of one or more modules. It's the modules that are the .EXE or .DLL files. – Dave Van den Eynde Apr 09 '09 at 12:16
  • 2
    True, you can merge modules into a single assembly. That's one of the MANY details I left out! –  Apr 09 '09 at 13:33
  • When you put it all together, what is difference between -> A process is created by the operating system and The application can spawn new processes? – variable May 13 '15 at 05:57
  • @variable the program is the compiled executable sitting on disk. The process is what the operating system creates when it loads the executable into memory and starts executing its code. –  May 13 '15 at 12:28
  • So when it comes to running .Net applications, would it be right to say that the OS starts a process. Within this process is its primary thread running an instance of the CLR. Within this instance of the CLR there is an AppDomain created. The .Net dll or exe runs here in this AppDomain. Correct? – user20358 Apr 26 '16 at 20:52
  • @user20358 close enough. If you want to learn about how it actually works, go out immediately and get a copy of CLR Via C#. I can't recommend it highly enough. –  Apr 27 '16 at 12:35
18

One of the biggest advantage of CLR's JIT compiler is - it prevents overlapping of processes' virtual address space. For example, if process 1 is spawned and the CLR (MScorEE.dll) is managing the execution of a managed assembly (.exe or .dll) within that process, then the JIT compiler will make sure that the virtual address space allocated to this process will not collide or overlap with the other adjacent processes. Having this advantage, it is now possible to re-use the single process for more than one managed code execution! Each managed code execution will have its own AppDomain and more than AppDomains could be part of a single process. This is what used by IIS and SQL Server (single process, many AppDomains).

Assembly is an abstract term that represents a single, re-usable component of managed code. Assembly consists of Metadata (PE32 or PE32+ header + IL header) and IL instructions. CLR's JIT compiler compiles and converts ILs of assembly into a machine specific instruction set, based on the processor and it's architecture (x86 or x64).

Process is what OS uses to facilitate the execution of a program. A process is a "RAM representation" of a program that has address space which consists of stack, heap, static and code region. Each process has a unique process Id associated with it.

Thread is a light weight process. A process has at least one thread (i.e. main thread) and depending upon the parallelism OS can create multiple threads within a single process and context-switch among them to support faster program execution. Threads can share some memory regions within a process.

quetzalcoatl
  • 32,194
  • 8
  • 68
  • 107
IntelligentBinary
  • 582
  • 1
  • 6
  • 15
  • 1
    correction: threads usually do not share stacks. They can read/modify stacks of each other if they really want it, but in general, each thread has its own stack. I've removed that wording from your post. Please recheck if it is what you meant. – quetzalcoatl Aug 23 '12 at 15:20
  • I agree. Threads have their own stack. Thank you for the correction. – IntelligentBinary Aug 24 '12 at 06:00