Introduction
Traditionally when many applications are executed on the same machine, they are isolated by something known as process. Ideally each application is loaded in its own process also known as address space. This isolation is need so that these applications do not tamper with other applications either intentionally or accidentally. Isolating applications is also important for application security. For example, one can run controls
from several Web applications in a single browser process in such a way that the controls cannot access each other's data and resources.
There are however many instances in which one would like an application to have the ability to communicate with other applications. Since these applications are loaded into different address spaces, there must be some form of context switching needed to allow one application to communicate with another. Inter process communication has to rely on operating systems support to manage this context switching and it is generally an expensive operation. Context switching means saving a process's context, it could also mean swapping the process out to virtual memory (to the page file stored on disk). If a single machine has a large number of active processes, the CPU is often reduced to swapping processes in and out of memory continuously, a phenomenon known as thrashing.
Application Domains
There should be a method by which the different applications can be executed in isolation from each other and which would also allow these applications to communicate with each other in a better way than offered by context switching. Microsoft .NET has introduced the Application Domain concept for precisely this reason. Application domains provide a secure and versatile unit of processing that the CLR can use to provide isolation between applications. Further, one can specify custom security policies on an Application Domain
to ensure that codes run in an extremely strict and controlled app domain. One can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of context switching between the processes. In Microsoft .NET, code normally passes a verification process before it can be executed. This code is considered as type-safe code
and this allows CLR to provide a great level of isolation at the process level. Type-safe codes have less chances of causing memory faults.
Code running in one application should not directly access code or resources from another application. The CLR enforces this isolation by preventing direct calls between objects in different application domains. Objects that pass between domains are either copied or accessed by proxy. If the object is copied, the call to the object is local. That is, both the caller and the object being referenced are in the same application domain. If the object is accessed through a proxy, the call to the object is remote. In this case, the caller and the object being referenced are in different application domains. As such, the metadata for the object being referenced must be available to both application domains to allow the method call to be JIT-compiled properly.
Application Domains And Assemblies
Before an assembly can be executed, it must be loaded into an application domain. By default, the CLR loads an assembly into an application domain containing the code that references it. In this way the assembly’s data and code are isolated to the application using it. In case, multiple application domains reference an assembly, the assembly’s code is shared amongst the different application domains. Such an assembly is said to be
domain-neutral. An assembly is not shared between domains when it is granted a different set of permissions in each domain. This can occur if the runtime host sets an application domain-level security policy. Assemblies should not be loaded as domainneutral if the set of permissions granted to the assembly is to be different in each domain.
Programming with Application Domains
Application domains are normally automatically created and managed by runtime hosts. However, Microsoft .NET also provides control to application developers to create and manage their own application domains. This would allow the developers to have control over loading and unloading the assemblies in different domains for performance reasons and maintain a high degree of isolation. Note that individual assemblies cannot be unloaded, the entire app domain has to be unloaded.
If development is being carried out with some code or components downloaded from the Internet, running it in its own application domain provides an excellent way to isolate the rest of the applications from this code.
The System namespace contains the class AppDomain. This class contains methods to create an application domain, to load and unload assemblies in the application domain.
An example will be useful to illustrate how application domains can be created and assemblies loaded and unloaded into the application domains. Note that only those assemblies that have been declared as Public can be loaded at runtime.
Copy and paste the following code into Notepad and save it as Display.cs/Display.vb, depending on the programming language used.
Display.vb
Code Listing in C#
using System;
public class Display
{
public static void Main()
{
Console.WriteLine("This is written by assembly 1");
Console.ReadLine();
}
}
Compiling in C#
Compilation csc /r:System.dll Display.cs
Code Listing in VB.NET
Imports System
Public Module Display
Sub Main()
Console.WriteLine("This is written by assembly 1")
Console.ReadLine()
End Sub
End Module
Compiling in VB.NET
vbc /r:System.dll Display.vb
Similarly, copy and paste the following code into Notepad and save it as Display2.cs/Display2.vb, depending on the programming language used. Display2.cs
Code Listing in C#
Imports System
Public Module Display
Sub Main()
Console.WriteLine("This is written by assembly 2")
Console.ReadLine()
End Sub
End Module
Compiling in C#
Compilation csc /r:System.dll Display2.cs
Code Listing in VB.NET
Imports System
Public Module Display
Sub Main()
Console.WriteLine("This is written by assembly 2")
Console.ReadLine()
End Sub
End Module
Compiling in VB.NET
'Compilation vbc /r:System.dll Display2.vb
The following code - CreateAppDomain.cs/CreateAppDomain.vb contains the following code that shows how to create an application domain programmatically and how to load assemblies during runtime.
Code Listing in C#
using System;
using System.Reflection;
public class CreateAppDomain
{
AppDomain m_objAppDomain;
public static void Main()
{
String strAppDomainName1 ;
String strAppDomainName2 ;
String strAssemblyToBeExecuted ;
strAppDomainName1 = "TestAppDomain1";
strAppDomainName2 = "TestAppDomain2";
strAssemblyToBeExecuted = "Display.exe";
CreateApplicationDomain(strAppDomainName1, strAssemblyToBeExecuted);
AppDomain.Unload(m_objAppDomain);
strAssemblyToBeExecuted = "Display2.exe" ;
CreateApplicationDomain(strAppDomainName2, strAssemblyToBeExecuted);
AppDomain.Unload(m_objAppDomain);
}
private void CreateApplicationDomain(String p_strAppDomainName , String
p_strAssemblyToBeExecuted)
{
try
{
m_objAppDomain = AppDomain.CreateDomain(p_strAppDomainName);
m_objAppDomain.ExecuteAssembly(p_strAssemblyToBeExecuted);
}
catch(AppDomainUnloadedException objException )
{
Console.WriteLine("Unable to create application domain");
Console.WriteLine("Exception is " + objException.toString());
}
}
}
Compiling in C#
Compilation csc /r:System.dll CreateAppDomain.cs
Code Listing in VB.NET
Imports System
Imports System.Reflection
Module CreateAppDomain
Dim m_objAppDomain As AppDomain
Sub Main()
Dim strAppDomainName1 As String
Dim strAppDomainName2 As String
Dim strAssemblyToBeExecuted As String
strAppDomainName1 = "TestAppDomain1"
strAppDomainName2 = "TestAppDomain2"
strAssemblyToBeExecuted = "Display.exe"
CreateApplicationDomain(strAppDomainName1, strAssemblyToBeExecuted)
AppDomain.Unload(m_objAppDomain)
strAssemblyToBeExecuted = "Display2.exe"
CreateApplicationDomain(strAppDomainName2, strAssemblyToBeExecuted)
AppDomain.Unload(m_objAppDomain)
End Sub
Private Sub CreateApplicationDomain(p_strAppDomainName As String,
p_strAssemblyToBeExecuted As String)
Try
m_objAppDomain = AppDomain.CreateDomain(p_strAppDomainName)
m_objAppDomain.ExecuteAssembly(p_strAssemblyToBeExecuted)
Catch objException As AppDomainUnloadedException
Console.WriteLine("Unable to create application domain")
Console.WriteLine("Exception is " & objException.toString())
End Try
End Sub
End Module
Compiling in VB.NET
Compilation vbc /r:System.dll CreateAppDomain.vb
Traditionally when many applications are executed on the same machine, they are isolated by something known as process. Ideally each application is loaded in its own process also known as address space. This isolation is need so that these applications do not tamper with other applications either intentionally or accidentally. Isolating applications is also important for application security. For example, one can run controls
from several Web applications in a single browser process in such a way that the controls cannot access each other's data and resources.
There are however many instances in which one would like an application to have the ability to communicate with other applications. Since these applications are loaded into different address spaces, there must be some form of context switching needed to allow one application to communicate with another. Inter process communication has to rely on operating systems support to manage this context switching and it is generally an expensive operation. Context switching means saving a process's context, it could also mean swapping the process out to virtual memory (to the page file stored on disk). If a single machine has a large number of active processes, the CPU is often reduced to swapping processes in and out of memory continuously, a phenomenon known as thrashing.
Application Domains
There should be a method by which the different applications can be executed in isolation from each other and which would also allow these applications to communicate with each other in a better way than offered by context switching. Microsoft .NET has introduced the Application Domain concept for precisely this reason. Application domains provide a secure and versatile unit of processing that the CLR can use to provide isolation between applications. Further, one can specify custom security policies on an Application Domain
to ensure that codes run in an extremely strict and controlled app domain. One can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of context switching between the processes. In Microsoft .NET, code normally passes a verification process before it can be executed. This code is considered as type-safe code
and this allows CLR to provide a great level of isolation at the process level. Type-safe codes have less chances of causing memory faults.
Code running in one application should not directly access code or resources from another application. The CLR enforces this isolation by preventing direct calls between objects in different application domains. Objects that pass between domains are either copied or accessed by proxy. If the object is copied, the call to the object is local. That is, both the caller and the object being referenced are in the same application domain. If the object is accessed through a proxy, the call to the object is remote. In this case, the caller and the object being referenced are in different application domains. As such, the metadata for the object being referenced must be available to both application domains to allow the method call to be JIT-compiled properly.
Application Domains And Assemblies
Before an assembly can be executed, it must be loaded into an application domain. By default, the CLR loads an assembly into an application domain containing the code that references it. In this way the assembly’s data and code are isolated to the application using it. In case, multiple application domains reference an assembly, the assembly’s code is shared amongst the different application domains. Such an assembly is said to be
domain-neutral. An assembly is not shared between domains when it is granted a different set of permissions in each domain. This can occur if the runtime host sets an application domain-level security policy. Assemblies should not be loaded as domainneutral if the set of permissions granted to the assembly is to be different in each domain.
Programming with Application Domains
Application domains are normally automatically created and managed by runtime hosts. However, Microsoft .NET also provides control to application developers to create and manage their own application domains. This would allow the developers to have control over loading and unloading the assemblies in different domains for performance reasons and maintain a high degree of isolation. Note that individual assemblies cannot be unloaded, the entire app domain has to be unloaded.
If development is being carried out with some code or components downloaded from the Internet, running it in its own application domain provides an excellent way to isolate the rest of the applications from this code.
The System namespace contains the class AppDomain. This class contains methods to create an application domain, to load and unload assemblies in the application domain.
An example will be useful to illustrate how application domains can be created and assemblies loaded and unloaded into the application domains. Note that only those assemblies that have been declared as Public can be loaded at runtime.
Copy and paste the following code into Notepad and save it as Display.cs/Display.vb, depending on the programming language used.
Display.vb
Code Listing in C#
using System;
public class Display
{
public static void Main()
{
Console.WriteLine("This is written by assembly 1");
Console.ReadLine();
}
}
Compiling in C#
Compilation csc /r:System.dll Display.cs
Code Listing in VB.NET
Imports System
Public Module Display
Sub Main()
Console.WriteLine("This is written by assembly 1")
Console.ReadLine()
End Sub
End Module
Compiling in VB.NET
vbc /r:System.dll Display.vb
Similarly, copy and paste the following code into Notepad and save it as Display2.cs/Display2.vb, depending on the programming language used. Display2.cs
Code Listing in C#
Imports System
Public Module Display
Sub Main()
Console.WriteLine("This is written by assembly 2")
Console.ReadLine()
End Sub
End Module
Compiling in C#
Compilation csc /r:System.dll Display2.cs
Code Listing in VB.NET
Imports System
Public Module Display
Sub Main()
Console.WriteLine("This is written by assembly 2")
Console.ReadLine()
End Sub
End Module
Compiling in VB.NET
'Compilation vbc /r:System.dll Display2.vb
The following code - CreateAppDomain.cs/CreateAppDomain.vb contains the following code that shows how to create an application domain programmatically and how to load assemblies during runtime.
Code Listing in C#
using System;
using System.Reflection;
public class CreateAppDomain
{
AppDomain m_objAppDomain;
public static void Main()
{
String strAppDomainName1 ;
String strAppDomainName2 ;
String strAssemblyToBeExecuted ;
strAppDomainName1 = "TestAppDomain1";
strAppDomainName2 = "TestAppDomain2";
strAssemblyToBeExecuted = "Display.exe";
CreateApplicationDomain(strAppDomainName1, strAssemblyToBeExecuted);
AppDomain.Unload(m_objAppDomain);
strAssemblyToBeExecuted = "Display2.exe" ;
CreateApplicationDomain(strAppDomainName2, strAssemblyToBeExecuted);
AppDomain.Unload(m_objAppDomain);
}
private void CreateApplicationDomain(String p_strAppDomainName , String
p_strAssemblyToBeExecuted)
{
try
{
m_objAppDomain = AppDomain.CreateDomain(p_strAppDomainName);
m_objAppDomain.ExecuteAssembly(p_strAssemblyToBeExecuted);
}
catch(AppDomainUnloadedException objException )
{
Console.WriteLine("Unable to create application domain");
Console.WriteLine("Exception is " + objException.toString());
}
}
}
Compiling in C#
Compilation csc /r:System.dll CreateAppDomain.cs
Code Listing in VB.NET
Imports System
Imports System.Reflection
Module CreateAppDomain
Dim m_objAppDomain As AppDomain
Sub Main()
Dim strAppDomainName1 As String
Dim strAppDomainName2 As String
Dim strAssemblyToBeExecuted As String
strAppDomainName1 = "TestAppDomain1"
strAppDomainName2 = "TestAppDomain2"
strAssemblyToBeExecuted = "Display.exe"
CreateApplicationDomain(strAppDomainName1, strAssemblyToBeExecuted)
AppDomain.Unload(m_objAppDomain)
strAssemblyToBeExecuted = "Display2.exe"
CreateApplicationDomain(strAppDomainName2, strAssemblyToBeExecuted)
AppDomain.Unload(m_objAppDomain)
End Sub
Private Sub CreateApplicationDomain(p_strAppDomainName As String,
p_strAssemblyToBeExecuted As String)
Try
m_objAppDomain = AppDomain.CreateDomain(p_strAppDomainName)
m_objAppDomain.ExecuteAssembly(p_strAssemblyToBeExecuted)
Catch objException As AppDomainUnloadedException
Console.WriteLine("Unable to create application domain")
Console.WriteLine("Exception is " & objException.toString())
End Try
End Sub
End Module
Compiling in VB.NET
Compilation vbc /r:System.dll CreateAppDomain.vb