Hey guys how are you?

After long conversation with my work colleague, I thought that I need to sharpen the evidences about Application Domains - aka AppDomain.

By .NET environment, the concept of an application domain, or AppDomain known as a process. The AppDomain is both a container and a boundary. The .NET runtime uses an AppDomain as a container for code and data, just like the operating system uses a process as a container for code and data. As the operating system uses a process to isolate misbehaving code, the .NET runtime uses an AppDomain to isolate code inside of a secure boundary.

An AppDomain belongs to only a single process, but single process can hold multiple AppDomains. An AppDomain is relatively cheap to create (compared to a process), and has relatively less overhead to maintain than a process. For these reasons, an AppDomain is a great solution for the ISP who is hosting hundreds of applications. Each application can exist inside an isolated AppDomain, and many of these AppDomains can exist inside of a single process – a cost savings.

Lets take an example from the REAL life:
Assume that you had created 2 ASP.NET aplpications in the same server, what will happen intior the system?

Firstable, the ASP.NET process that runs the web application will run both the applications (you can find the process name in the task manager as aspnet_wp.exe in Windows XP or as w3wp.exe in Windows 2003. Each application will have its own AppDomain including its Cache, Application, and Session objects.
BUT, the code of the same application runs under the same process!

What about static members or shared classes? In this case, each ApDomain will have its own copy of the static members (fields), but of course, the data and code is not shared and will be held safely isolated and inside of a boundary provided by the AppDomain.

Load some new assemblies..
Suppose you want to load an updated dll into the application folder or subdirectory, the ASP.NET runtime will recognize it and and will start a new AppDomain because it cannot insert it to the running AppDomain, the result is that running requests will finish its work and after it they will work against the new AppDomain that holds the new dll and executing code.

Last word...
I think that one of the good adventages of the AppDomain is that you can allocate the wanted memory for your application (under its AppDomain) as much as you want (bounded by the process capability of course) and if there is a runtime crash, the rest of the applciations that runs over the current process will not crash.

I will glad to hear some comments and additions... :)