What is a .NET application domain?

In particular, what are the implications of running code in two different application domains?

How is data normally passed across the application domain boundary? Is it the same as passing data across the process boundary? I'm curious to know more about this abstraction and what it is useful for.

EDIT: Good existing coverage of the AppDomain class in general at https://stackoverflow.com/questions/622516/i-dont-understand-appdomains

An AppDomain basically provides an isolated region in which code runs inside of a process.

An easy way to think of it is almost like a lighter-weight process sitting inside of your main process. Each AppDomain exists within a process in complete isolation, which allows you to run code safely (it can be unloaded without tearing down the whole process if needed), with separate security, etc.

As to your specifics - if you run code in 2 different AppDomains within a process, the code will run in isolation. Any communication between the AppDomains will get either serialized or handled via MarshallByRefObject. It behaves very much like using remoting in this regard. This provides a huge amount of security - you can run code that you don't trust, and if it does something wrong, it will not affect you.

There are many more details in MSDN's description of Application Domains.

It is an isolation layer provided by the .NET runtime. As such, App domains live with in a process (1 process can have many app domains) and have their own virtual address space.

App domains are useful because:

• They are less expensive than full processes
• They are multithreaded
• You can stop one without killing everything in the process
• Segregation of resources/config/etc
• Each app domain runs on its own security level

If you look at it from processor internal details perspective it sets different value for Code Segment (the CS) register. code and CS:IP (Instruction Pointer) register is the one that is in execution by the processor.

(I've chosen to skim page table related discussion for brevity).

AppDomain marks this boundary. for code safety.

The reason for giving this background is to get away with question of these sort:

1. how can we access resource across two app domain (yes using pipes or some other sharing mechanis not directly as CS:IP cant be set to some other appdomain. It is just the OS that can do it. Not the CLR)

2. Could there be multiple threads in app domain. Technically yes as the CS value going to be in the current process. you can change IP to something else by a jump statement (function call/goto combination)

3. can two threads in two different app domain communicate (No. refer point 1.)

4. can two threads in single app domain communicate (Yes. refer point 2)

several other combination of these cases could be answered by little knowledge of how CS:IP works.

Each application running within a process, AppDomain is also a light-weight process or we can say logical unit which having group of assemblies (this is a container which contain group of assemblies ) and this exist inside of the process at isolation level of same process, this allows to run multiple assemblies within same process and prevent them for direct access.

Running Dot Net Application Within AppDomain: Once any dot net application run, Operation system shell load CLR into a process and new AppDomain been created in the same process and load all the assemblies in the created AppDomain, now from the AppDomain code will get executed.

When to Custom AppDomain: We can create own AppDomain, now the thing is in which scenario we can create own AppDomain. Suppose run time we need to add or remove the assemblies without interruption the running application then we can create own AppDomain.