The .Net
framework has implemented all the functionality related to Application
Domain in the class, System.AppDomain. AppDomain class is used to create
and terminate Application Domains, load and unload assemblies, enumerate
assemblies and threads in a domain. It also has methods to create a new
instance of specified type defined in an assembly file, executes assembly,
define privileges, get value stored for a specified name in the current
application domain, etc. This class cannot be inherited.
AppDomain
class also implements a set of events that can be handled by the application
to take actions during that event. Some of the events are loading and
unloading of the assembly, occurrence of an unhandled exception, etc.
Following are the steps typically used while using Application Domains:
• Create an instance of Application Domain class by calling AppDomain.CreateDomain(Since
there is no constructor for this class, this is the only method to instantiate
an Application Domain)
• Load the required assembly in an Application Domain, by calling
AppDomain.Load and execute it by calling the method, AppDomain.ExecuteAssembly.
• Unload the Application Domain by calling static method, AppDomain.Unload.
Configuring Application Domain
The Application Domain used for launching assemblies can be configured
programmatically to the customized environments. The necessity for configuring
the Application domain arises mostly when it has to be restricted with
limited privileges for reducing the risk associated with security vulnerabilities.
In addition to allowing the assembly to execute in isolation, configuration
helps to avoid the damage that can be caused to the system by the malicious
code (if any) by the attacker.
The .Net class, AppDomainSetup class is used for setting up configuration
information for a new Application domain during its creation (by passing
its instance as a parameter). The properties thus setup are used by the
run-time hosts to configure a particular Application domain. Some of the
most useful properties that can be configured include security and trust
information, name of root directory containing the application, configuration
file, etc. The changes in the properties will not be applicable to the
Application Domains that are already created.
Another alternate method for setting limited privileges to the Assembly
is by using the System.Security.Policy.Evidence object. Evidence is the
information gathered by the runtime about the assembly to determine the
code group that it belongs to. This would get the privileges of the assembly.
Examples of evidence include folder or web site executing, digital signatures,
etc. It is generally preferred to use Internet_zone code group which assigns
highly restrictive permission set for the assembly.
This Evidence object is passed to the ExecuteAssembly method of Application
Domain instance as a parameter to execute the assembly with the required
level of security.
Benefits of Application Domain
Security:
The main intention of creating multiple Application Domains to load different
instances of assemblies is to restrict each assembly for access to resources
of other assemblies and execute any action on them. In addition to this
level of security, the host in which the Application domains are created
can be configured to code-access security policy and role-based security
policy with which the execution of the code in the domain can be controlled
to the desired level.
Reliability:
Reliability of an application is mainly needed when there are processes
which need to be available throughout the execution of the system (like
server process) without getting restarted. For this, the core task which
cannot get terminated has to be isolated from the remaining ones and loaded
in a separate Application Domain. Alternatively, the task that might cause
a process to terminate can be isolated by loading it in a separate Application
domain so that the main process is not disturbed. Also, application domains
are used to isolate tasks that should not share data.
Efficiency:
Sometimes, there can be chances to unload some assemblies since it is
not required after certain period of execution of the application. If
the assembly is loaded into the default Application domain, it cannot
be unloaded from the running process. However if it was loaded in a separate
Application domain, this can be unloaded and hence free up resources.
This technique can be used for long-running processes which rarely use
large dynamic-link libraries (DLLs).
