AppDomain is a model for scoping the execution of code and the ownership of resources. Many programming technologies and enviroments define their own unique models for this purpose. For an operating system, the model is based on processes. For Java VM, it is based on class loaders. For IIS and ASP, the scoping model is based on virtual directory.
The .NET Framework runs on top of Microsoft Windows. This means that the .NET Framework must be built using the technologies that Windows can interface with. To begin with, all managed module and assembly files must first use the Windows Portable Executable (PE) file format and be either a Windows EXE file or a DLL.
When delveloping the CLR, Microsoft implement it as a COM server contained inside a DLL, that is, Microsoft defiend a standard COM interface for the CLR and assigned GUIDs to this interface and the COM server.
Any Windows application can host the CLR. When the CLR COM server initializes, it create an AppDomain. AppDomain is a logical container for a set of assemblies. The first AppDomain created when the CLR is initialized is called the default AppDomain, this AppDomain is destroyed only when the Windows process ends.
AppDomains is quite like an operating system process. But note that a process is an abstraction created by the operating system, while an AppDomain is an abstraction created by the CLR. A given AppDomain resides in exactly one OS process, a given OS process can host multiple AppDomains.
It is much efficient to create an AppDomain than to create an OS process. Also it is cheaper to cross AppDomain boundries than to cross process boundries.
With CAS and AppDomain, you can run partially trusted code in a sandbox.
AppDomain usages:
Basic ones:
1. AppDomain tutorials
More complex ones:
1. Use AppDomains To Reduce Memory Consumption in .NET applications
2. Loading Assemblies in Separate Directories Into a New AppDomain
Also
"An application domain is the CLR equivalent of an operation system’s
process. An application domain is used to isolate applications from one
another. This is the same way an operating system process works. The
separation is required so that applications do not affect one another.
This separation is achieved by making sure than any given unique
virtual address space runs exactly one application and scopes the
resources for the process or application domain using that addess space.
However, a CLR application domain is seperate from a process. It is
contained within an operating system process. A single CLR operating
system process can contain multiple application domains. There are some
major pluses to having application domains within a single process.
Lower system cost – many application domains can be contained within a single sytem process.
The application in an application domain can be stopped
without affecting the state of another application domain running in
the same process.
A fault or exception in on application domain will not
affect other application domains or crash the entire process that hosts
the application domains.
Configuration information is part of an application domains scope, not the scope of the process.
Each application domain can have different security access levels assigned to them, all within a single process.
Code in one application domain cannot directly access code in another application domain. (* see below)
So you see, the CLR is like a mini-operating system. It runs a
single process that contains a bunch of sub-process, or application
domains.
* Direct communication cannot be acheived across application domains.
Application domains can still talk to eachother by passing objects via
marshalling by value (unbound objects), marshalling by reference
through a proxy (AppDomain-bound objects). There is a third type of
object called a context-bound object which can be marshalled by
reference across domains and also within the context of its own
application domain. Because of the verifiable type-safety of managed
code, the CLR can provide fault isolation between domains at a much
lower cost than an operating system process can. The static type
verification used for isolation does not require the same process
switches or hardware ring transitions that an operating system process
requires."
The .NET Framework runs on top of Microsoft Windows. This means that the .NET Framework must be built using the technologies that Windows can interface with. To begin with, all managed module and assembly files must first use the Windows Portable Executable (PE) file format and be either a Windows EXE file or a DLL.
When delveloping the CLR, Microsoft implement it as a COM server contained inside a DLL, that is, Microsoft defiend a standard COM interface for the CLR and assigned GUIDs to this interface and the COM server.
Any Windows application can host the CLR. When the CLR COM server initializes, it create an AppDomain. AppDomain is a logical container for a set of assemblies. The first AppDomain created when the CLR is initialized is called the default AppDomain, this AppDomain is destroyed only when the Windows process ends.
AppDomains is quite like an operating system process. But note that a process is an abstraction created by the operating system, while an AppDomain is an abstraction created by the CLR. A given AppDomain resides in exactly one OS process, a given OS process can host multiple AppDomains.
It is much efficient to create an AppDomain than to create an OS process. Also it is cheaper to cross AppDomain boundries than to cross process boundries.
With CAS and AppDomain, you can run partially trusted code in a sandbox.
AppDomain usages:
Basic ones:
1. AppDomain tutorials
More complex ones:
1. Use AppDomains To Reduce Memory Consumption in .NET applications
2. Loading Assemblies in Separate Directories Into a New AppDomain
Also
"An application domain is the CLR equivalent of an operation system’s
process. An application domain is used to isolate applications from one
another. This is the same way an operating system process works. The
separation is required so that applications do not affect one another.
This separation is achieved by making sure than any given unique
virtual address space runs exactly one application and scopes the
resources for the process or application domain using that addess space.
However, a CLR application domain is seperate from a process. It is
contained within an operating system process. A single CLR operating
system process can contain multiple application domains. There are some
major pluses to having application domains within a single process.
Lower system cost – many application domains can be contained within a single sytem process.
The application in an application domain can be stopped
without affecting the state of another application domain running in
the same process.
A fault or exception in on application domain will not
affect other application domains or crash the entire process that hosts
the application domains.
Configuration information is part of an application domains scope, not the scope of the process.
Each application domain can have different security access levels assigned to them, all within a single process.
Code in one application domain cannot directly access code in another application domain. (* see below)
So you see, the CLR is like a mini-operating system. It runs a
single process that contains a bunch of sub-process, or application
domains.
* Direct communication cannot be acheived across application domains.
Application domains can still talk to eachother by passing objects via
marshalling by value (unbound objects), marshalling by reference
through a proxy (AppDomain-bound objects). There is a third type of
object called a context-bound object which can be marshalled by
reference across domains and also within the context of its own
application domain. Because of the verifiable type-safety of managed
code, the CLR can provide fault isolation between domains at a much
lower cost than an operating system process can. The static type
verification used for isolation does not require the same process
switches or hardware ring transitions that an operating system process
requires."
This comment has been removed by the author.
ReplyDelete