What's the meaining of AppDomain?

Enter the .Net AppDomain

Conclusion:

1. Why draw Application Domain concept into .Net?
1. To improve security of applications
   
2. To avoid application crashes caused by memory leak, null object referencing, out of memory boundaries etc.
3. To avoid applications running in the same process affect each other
   
2. What is Application Domain?
1. The main purpose of an Application Domain is to isolate our applications from other applications. Application domains run on a single Win32 process. The same solution that we just mentioned above can use an application domain and at the same time, limit on the possibility of errors and crashes due to memory leaks.
3. What's the advantage of it?
1. Objects in the same Application Domain communicate directly while Objects that exists in different Application Domains interact with each other by transporting copies of objects to each other or by using proxies for message exchange (by reference).
2. Another advantage of using an Application Domain is that we can destroy it through the host (eg: ASP.Net) without affecting other Application Domains that exist within that Win32 process. Hence our work on the Application Domain can be Independent.
3. Further, we can also use Application Domains to unload types by destroying the Application Domain that we have loaded it into.
4. Practically speaking, Application Domains play a critical security and functional role especially when we're creating applications that do remoting like running web services.
5. 
   
4. 
   

Reading Notes:

1. Each Win32 process contains at the least one thread (eventually we end up running multiple threads) and if we are to run other tasks or open up other applications through our application, these tasks will belong to our particular Win32 process running on a collection of multiple threads.
2. One of the characteristics of a Win32 process is that it is very much similar to a virtual boundary.
1. It's pretty easy to communicate within a process but the same is restricted to a certain level outside that particular Win32 process.
2. To interact with other Win32 processes, we would require some special mechanisms to work on as there are a couple of security contexts we would have to take into consideration and also the need to restrict what a Win32 process can and should do on a particular system.
3. Doing so can lead to frequent crashes (oh boy...so used to this part in windows!) where one process using up the memory allocated to another process can lead to unstable environments that eventually…. you know…as usual....just CRASH!
4. These frequent crashes and run-time errors are usually caused due to inefficient use of memory leading to memory leaks, null object referencing, out of memory bounds and blah blah blah.
5. Running a host of multiple applications within a single process will enable us to use fewer resources. This would even result to faster execution.
6. But here's another everyday scenario: incase one application crashes, every other application within this process goes down like a deck of cards!
7. The main purpose of an Application Domain is to isolate our applications from other applications. Application domains run on a single Win32 process. The same solution that we just mentioned above can use an application domain and at the same time, limit on the possibility of errors and crashes due to memory leaks.
8. Hence we're running an application within an application domain and we further run multiple application domains within a single Win32 process.
9. With the CLR's ability to run managed code, we're further cutting down on leaks and crashes (and also thanks to the CLR's Garbage Collector).
10. Objects in the same Application Domain communicate directly while Objects that exists in different Application Domains interact with each other by transporting copies of objects to each other or by using proxies for message exchange (by reference).
11. It's actually a pretty neat light weight process that runs within a single Win32 process.
12. Another advantage of using an Application Domain is that we can destroy it through the host (eg: ASP.Net) without affecting other Application Domains that exist within that Win32 process. Hence our work on the Application Domain can be Independent.
13. Further, we can also use Application Domains to unload types by destroying the Application Domain that we have loaded it into.
14. The amazing .Net runtime enforces Application Domain isolation by ensuring control over memory use and therefore all the memory that is used by the Application Domains within a Win32 process is managed by the .Net runtime and therefore we are avoiding all the problems that we mentioned initially such as one application accessing another application's memory and hence avoiding runtime errors followed by crashes.
15. Hence we're actually using a security layer that isolates current applications from talking to other applications.
16. Practically speaking, Application Domains play a critical security and functional role especially when we're creating applications that do remoting like running web services.
17. Inheriting the System.MarshalByRefObject base class into our applications, we can create objects that communicate between and across different application domains.
18. 
    

.Net Cross AppDomain Communication