Published:
16 Aug 2006
|
Abstract
In this article Joydip provides a detailed analysis of Application Domains, how they work and their differences with a process. |
|
by Joydip Kanjilal
Feedback
|
Average Rating:
Views (Total / Last 10 Days):
54002/
124
|
|
|
Introduction |
An Application Domain is a light-weight process. It is a
logical and physical unit of isolation built around every .NET application by
the Common Language Runtime (CLR) and contains its own set of code, data and configuration
settings. Multiple application domains can exist simultaneously in the same
process. The default application domain is created when the Common Language
Runtime is first loaded into a process. From then on, the CLR loads an
assembly implicitly into an Application Domain the first time it encounters and
references a type in the MSIL code. Assemblies can also be created explicitly
loaded in Application Domains. This article discusses what Application Domains
are and the differences between Application Domains and Processes. It also
discusses Default Domains and how Application Domains can be created, loaded
and unloaded explicitly.
|
What is an Application Domain? |
An Application Domain is a light weight process and provides
a logical and physical isolation from another .NET application. This ensures
that the Applications can work independent and isolated of each other. An
Application Domain is created by the Common Language Runtime (CLR) and it
ensures that if one Application Domain crashes or goes down, it does not in any
way effect the functioning of another Application Domain. Multiple .NET
applications can be executed in one single process by loading these
applications in separate Application Domains. Several threads can be executing
in a single application domain at any given time and a particular thread is not
confined to a single application domain. In other words, threads are free to
cross application domain boundaries and a new thread is not created for each
application domain. The following are the benefits of Application Domains.
Isolation of code, data and configuration information of one
application from another
A failure in one application will not affect the other
|
What are Runtime Hosts? |
When we create an application in .NET, regardless of the
type of the application (Console Applications, Windows applications, Web
services, etc), it has to be hosted by a Win32 process. This is because none
of these are Win32 applications. This process is what we call the Runtime
Host. The following are the runtime hosts shipped with .NET Framework:
ASP.NET, IE and Shell. It is also possible to write our own Runtime host using
some Microsoft APIs.
|
Application Domains and Processes |
Every application has a process space in which it is
executed. This provides isolation between processes that ensures that code in
one process does not have direct access to the code in another process. An
application domain is lighter than a process and therefore, it is referred to
as a light weight process. Application domains are appropriate for scenarios
that require isolation without the heavy cost associated with running an
application within a process. In other words, an Application domain provides a
secure and versatile unit of processing that the common language runtime can
use to provide isolation between applications running in the managed
environment of Microsoft .NET. It should be noted here that applications that
run on different Application Domains can only share information by using Microsoft
.NET's Remoting technology. A process is the running instance of a program and
is characterized by a change of state and attributes and identified by having a
Process Control Block of its own. A process runs exactly one application and
has its own virtual address space, executable code and data. Like an
Application Domain, a process is not permitted to access the code or data of
another process. The exact behavior of a particular process is based on the
operating system on which it executes. Multiple applications can execute
within a single process by loading them into separate application domains.
|
Default Domains |
A default domain is an application domain that gets loaded whenever
the CLR is loaded and is not unloaded until the process terminates.
|
Creating an Application Domain |
The AppDomain class abstracts
application domains. An Application domain can be created using AppDomain class of System namespace, but in most cases they
are created and managed by the runtime hosts that execute the application's code.
An Application Domain is created using one of the following overloaded
CreateDomain methods of the System.AppDomain class.
Listing 1
public static AppDomain CreateDomain(String appDomainName)
public static AppDomain CreateDomain(String appDomainName, Evidence securityInformation)
public static AppDomain CreateDomain(String appDomainName,
Evidence securityInformation, AppDomainSetup appDomainSetupInformation)
public static AppDomain CreateDomain(String name,
Evidence securityInformation, String appBasePath, String appRelativeSearchPath,
bool shadowCopyFiles)
All these overloaded methods are static in nature and can be
invoked without instantiating the class. The first overloaded method accepts
the name of the Application Domain to be created and creates an Application
Domain. However, the second accepts two parameters; the first one being the
name of the Application Domain to be created while the second is a reference of
the System.Security.Policy.Evidence for specifying
the security policy for the application. The third overload accepts an
additional parameter, a reference of System.AppDomainSetup,
which is used to configure how the assemblies would be loaded into the
application. The Evidence parameter refers to a collection of the security
information on the application domain. The last overloaded CreateDomain method
accepts some additional parameters without defining a System.AppDomainSetup
object reference. The return value of each of these overloaded methods is an
AppDomain object that represents the newly created application domain.
|
Configuring Application Domains |
The properties ApplicationBase and ConfigurationFile
belonging to the The AppDomainSetup class provide the control on how assemblies
are loaded into an application domain. While the former defines the root
directory for an application, the latter is concerned with defining the XML
file that contains the configuration settings related to versioning information
and policies for the application that executes in the application domain. Refer
to the third overloaded CreateDomain method shown earlier to understand how to
create an Application Domain and provide the configuration information. The
following is the property that is used to retrieve the configuration
information from an Application Domain.
Listing 2
public AppDomainSetup SetupInformation { get; }
|
Executing an Application in a Remote Application Domain |
The ExecuteAssembly method of the AppDomain class belonging
to the System namespace is used to execute an assembly in an Application
Domain. The following are the overloaded versions of the ExecuteAssembly
method.
Listing 3
public int ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
public int ExecuteAssembly(String assemblyFile, Evidence assemblySecurity)
public int ExecuteAssembly(String assemblyFile)
The following is the source code given to illustrate how we
can execute a remote assembly in an Application Domain.
Listing 4
using System;
using System.Runtime.Remoting;
using System.Reflection;
public class ExecuteAssemblyApplication
{
public static void Main( String[] args )
{
AppDomain appDomain = AppDomain.CreateDomain("RemoteDomain");
appDomain.ExecuteAssembly(@"C:\Test.exe");
appDomain. CreateInstanceFrom(@"C:\Test.exe", " ExecuteAssembly.Test");
//Some code
AppDomain.Unload(appDomain);
}
}
}
The following is the source code for the Welcome class of
the Welcome.exe assembly that has been used in the previous listing.
Listing 5
using System;
using System.Threading;
namespace ExecuteAssembly
{
public class Test
{
public static void Main(String[] args)
{
Console.WriteLine("Application Domain: " + Thread.GetDomain().Name);
}
}
}
|
Loading an Assembly in an Application Domain |
The Load method of the System.AppDomain
class can be used to Load an assembly in an Application Domain provided the
Application Domain concerned is not the current Application Domain and the
necessary configuration settings for the two Application Domains are not the
same. The System.AppDomain provides the following
methods for loading an assembly into an application domain.
Listing 6
public Assembly Load(AssemblyName assemblyReference)
public Assembly Load(AssemblyName assemblyReference, Evidence evidence)
public Assembly Load(AssemblyName assemblyReference, Evidence evidence, String callerLocation)
public Assembly Load(byte[] assembly)
public Assembly Load(byte[] assembly, byte[] assemblyStore)
public Assembly Load(byte[] assembly, byte[] assemblyStore, Evidence evidence)
public Assembly Load(String assemblyName)
public Assembly Load(String assemblyName, Evidence evidence)
public Assembly Load(String assemblyName, Evidence evidence, String callerLocation)
|
Unloading an Assembly from an Application Domain |
The Common Language Runtime has no support to unload an
assembly. We can only unload the Application Domain in which the assembly has
been loaded. This is discussed in the following section.
|
Unloading an Application Domain |
The Unload method shuts down an Application Domain. The
Garbage Collector does a full garbage collection when it unloads an App Domain,
so the resources that have been used in an App Domain should be reclaimed when
it is unloaded. The following static method of the System.AppDomain class is
used to unload an Application Domain.
Listing 7
public static void Unload(AppDomain domain)
This method accepts an AppDomain object that represents the
Application Domain to be unloaded. Note that if the thread on which the Unload
method is called is executing in the domain to be unloaded, another thread is
started with a view to perform this unload operation.
|
References |
|
Conclusion |
Application Domains are a unit of abstraction between
threads and processes. They provide isolation and security boundaries for
executing managed code in .NET's managed environment. It is possible to have
multiple Application Domains in a process and multiple threads running in an
Application Domain, but every application will only reside in its Application
Domain. Each ASP.NET application will run in its own application domain, but
under the same worker process of ASP.NET called aspnet_wp.exe. It should be
noted that the ASP.NET Worker Process is aspnet_wp.exe in IIS 5.0 or w3wp.exe
in IIS 6.0 versions. Therefore, we may state that there lies a one-to-one
correlation between application domains and threads. This article has provided
a detailed insight into the concepts of Application Domains and how they can be
used programmatically in Microsoft .NET's managed environment.
|
|
|
User Comments
Title:
Answer to reader's queries
Name:
Joydip Kanjilal
Date:
2006-11-15 3:44:34 PM
Comment:
Dear All,
Thanks a lot for the comments. Please note that an Application Domain belongs to only a single process, but a single process can hold multiple Application Domains. This is what I wanted to highlight in this article. Please let me know by e-mail or otherwise, if you still have any confusions.
Regards,
Joydip.
|
Title:
it is nice
Name:
gir
Date:
2006-11-06 7:59:31 AM
Comment:
everything is cool!
|
Title:
Rewrite please
Name:
Juan Romero
Date:
2006-10-25 5:50:22 PM
Comment:
This is a great article but some things seem contradictory. For example "A process runs exactly one application and has its own virtual address space, executable code and data." and "Multiple applications can execute within a single process by loading them into separate application domains.". Hopefully the author rewrites this article. It is an interesting topic.
|
Title:
Examples would be helpful
Name:
Reader
Date:
2006-10-13 9:11:12 PM
Comment:
It would be nice to read about some examples of why I would want to use application domains. Not necessarily code to do it, but real world reasons to use them and how the system would benefit vs. not using app domains.
|
Title:
suggestion
Name:
reader
Date:
2006-10-13 5:17:38 PM
Comment:
Every application has a process space in which it is executed. This provides isolation between processes that ensures that code in one process does not have direct access to the code in another process. An application domain is lighter than a process and therefore, it is referred to as a light weight process. Application domains are appropriate for scenarios that require isolation without the heavy cost associated with running an application within a process. In other words, an Application domain provides a secure and versatile unit of processing that the common language runtime can use to provide isolation between applications running in the managed environment of Microsoft .NET. It should be noted here that applications that run on different Application Domains can only share information by using Microsoft .NET's Remoting technology. A process is the running instance of a program and is characterized by a change of state and attributes and identified by having a Process Control Block of its own. A process runs exactly one application and has its own virtual address space, executable code and data. Like an Application Domain, a process is not permitted to access the code or data of another process. The exact behavior of a particular process is based on the operating system on which it executes. Multiple applications can execute within a single process by loading them into separate application domains.
I don't the difference between the process and app domain in the above paragraph. should be rewritten.
|
Title:
Thread Pools in AppDomains
Name:
David Martin
Date:
2006-10-13 5:14:40 AM
Comment:
Good article. Clearly explained. It was very helpful for some of junior developers on my team. You discuss thread relationships at the end as a one to one relationship between application domain and thread. I think this is slightly mis-laeding. The thread is abstracted from the app domain, described as a soft thread - with the true process thread described as a hard thread. The relationship between a hard thread and a soft thread is one per AppDomain, every time a hard thread enters an AppDomain it is always associated with the same soft thread of execution (unless it has changed in framework 2.0). The hard thread TLS contains data references to soft threads in different AppDomains within the same process. The CLR abstraction provides us a soft thread TLS. So if there are 3 AppDomains each using 3 threads which would represnet 9 soft threads the process and OS may only be consuming 3 Hard (OS) threads.
I hope this is of help to someone. I have a presentation explaining this which I will upload somewhere - in the mean time if anyone wants it drop me a line at mrdavemartin@hotmail.co.uk
|
Title:
Good
Name:
kesavan
Date:
2006-10-09 7:14:42 AM
Comment:
Nice Article
|
Title:
App serialization and restart?
Name:
C
Date:
2006-08-31 12:09:01 PM
Comment:
Can you cover how to start an application in an application domain, pause it, save it to disk, load it back into an application domain and then restart the application from its paused state?
|
Title:
good
Name:
sara
Date:
2006-08-31 9:27:17 AM
Comment:
very good article. many thanks to the author
|
Title:
EXCELENT
Name:
Mahesh
Date:
2006-08-22 2:24:48 AM
Comment:
GOOD ONE
|
Title:
acknowledgement
Name:
Sagar Debnath
Date:
2006-08-17 6:57:02 AM
Comment:
Gud article about appdomain in .net.
|
|
Product Spotlight
|
|