4 The CLR (Common Language Runtime) The CLR (Common Language Runtime) is the central element to the .NET platform architecture. The CLR is a software layer which manages the execution of .NET application code. The word ‘manage’ covers a wide range of operations needed for the execution of managed applications. Here are a few: • Hosting of multiple applications in a single Windows process; • Compilation of IL code into machine language code; • Exception management; • Destruction of unused objects; • Loading of applications and assemblies; • Resolving of types. The CLR is conceptually close to what is commonly known as the virtual machine in Java. Application Domains (AppDomain) Introduction An application domain (which we will commonly refer to as an AppDomain) can be seen as a light- weight process. A Windows process can contain many AppDomains. The notion of AppDomain is used so that a physical server can host several applications. For example, ASP.NET takes advan- tage of AppDomains to host, within a single process, a multitude of web applications. In fact, the Microsoft stress tests create up to 1000 simple web applications within a single process. The performance gain from the use of AppDomains is two fold: • The creation of an AppDomain requires less system resources than the creation of a Windows process. • AppDomains hosted in the same Windows process share the same resources such as the CLR, the base .NET types, the addressing space and threads. When an assembly is executed, the CLR automatically creates a default AppDomain for the execution. Each AppDomain has a name and the default AppDomain has the name of the executed assembly (including the .exe extension). If a single assembly is loaded within multiple AppDomains, there are two possible behaviors: • Either the CLR will load the assembly multiple times, once for each AppDomain in the process. • Either the CLR will load the assembly a single time outside of all the AppDomains in the process. The assembly can then be used by all the AppDomains within the process. Such an assembly is said to be domain neutral. We’ll see a little later in this chapter that the choice of this behavior can be configured. The default behavior being to load the assembly multiple times as needed. 72 Chapter 4 - The CLR (Common Language Runtime) Threads and AppDomains Do not confuse the notions of ‘threads’ and ’application domains’. There is no notion of ownership between the threads of a process and the AppDomains within this process. Let us remind you that this is not the case for processes since the threads belong to a single process and that each process can have one or multiple threads. In reality, a thread is not confined to a single AppDomain and that at any given time, multiple threads can execute within the context of the same AppDomain. Let there be two AppDomains DA and DB hosted within the same process. Suppose that a method from object A, for which the assembly is contained in DA, calls a method of object B, where the assembly resides in DB. In this case, the same thread will execute both the caller and the called methods. This thread will essentially cross the boundary between the DA and DB AppDomains. In other words, the concepts of threads and AppDomains are orthogonal. Unloading an AppDomain Once an assembly is loaded inside an AppDomain, you cannot unload it from this AppDomain. However, you can unload an AppDomain as a whole. This operation has some big consequences since the threads which are currently executing within the AppDomain must be aborted by the CLR and problems can occur when some of these are executing non-managed code. All managed objects within the application domain must also be garbage collected. We recommend against having an architecture which depends on the frequent load/unload of AppDomains. We’ll see that type of architecture is sometimes a necessary evil when implementing servers which require a high availability rate (99,999% of the time such as SQL Server 2005). AppDomains and isolation Isolation between AppDomains comes from the following characteristics: • An AppDomain can be unloaded independently from other AppDomains. • An AppDomain does not have access to assemblies and objects from other AppDomains. • An AppDomain can have its own exception management strategy as long as it does not let an exception exit from its bounds meaning that problems from within an AppDomain will not affect the other domains within the same process. • Each AppDomain can define its own security strategy for code access to an assembly. • Each AppDomain can define its own rules in regard to how the CLR will locate the assemblies before loading them. The System.AppDomain class An instance of the System.AppDomain class is a reference to an AppDomain within the current process. The static property CurrentDomain{get;} of this class allows you to get a reference to the current AppDomain. The following example illustrates the use of this class to enumerate the assemblies loaded in the current AppDomain: Example 4-1 using System; using System.Reflection; // For the Assembly class. class Program { static void Main() { AppDomain curAppDomain = AppDomain.CurrentDomain; foreach ( Assembly assembly in curAppDomain.GetAssemblies() ) Console.WriteLine( assembly.FullName ); } } Application Domains (AppDomain) 73 Hosting several applications in a single process The AppDomain class contains the CreateDomain() static method that allows the creation of a new AppDomain within the current process. This method offers multiple overloaded variations. To use this method, you must specify the following: • (mandatory) A name for your AppDomain; • (optional) The security rules for the CAS on this new AppDomain (with an object of type System.Security.Policy.Evidence) ; • (optional) Information that allows the location mechanism of the CLR for this AppDomain (with an object of type System.AppDomainSetup). The two important properties of a System.AppDomainSetup are: • ApplicationBase: This property defines the base directory for the AppDomain. This directory is used by the assembly locating mechanism of the CLR when loading assemblies into this AppDomain. • ConfigurationFile: This property references a configuration file for the AppDomain. This file is a XML file containing information about versioning and locating rules to be used in the AppDomain. Now that you know how to create an application domain, we can present to you how you can load and execute an assembly within this domain by calling the System.AppDomain. ExecuteAssembly() method. The assembly must be an executable and the flow of execution will start at its entry point. Note that the thread calling ExecuteAssembly() will be executing the loaded assembly. This illustrates how a thread can cross the boundaries between AppDomains. Here is a C# example. The first piece of code is the assembly which will be loaded by the assembly defined in the second segment of code: Example 4-2 AssemblyToLoad.exe using System; using System.Threading; public class Program { public static void Main() { Console.WriteLine( “Thread:{0} Hi from the domain: {1}”, Thread.CurrentThread.Name, AppDomain.CurrentDomain.FriendlyName); } } Example 4-3 AssemblyLoader.exe using System; using System.Threading; public class Program { public static void Main() { // Name the current thread. Thread.CurrentThread.Name = “MyThread”; // Create an AppDomainSetup instance. AppDomainSetup info = new AppDomainSetup(); info.ApplicationBase = “file:///”+ Environment.CurrentDirectory; // Create a new appdomain without security parameters. AppDomain newDomain = AppDomain.CreateDomain( “NewDomain”, null, info); Console.WriteLine( 74 Chapter 4 - The CLR (Common Language Runtime) Example 4-3 AssemblyLoader.exe “Thread:{0} Calling ExecuteAssembly() from appdomain {1}”, Thread.CurrentThread.Name, AppDomain.CurrentDomain.FriendlyName ); // Load the assembly ‘AssemblyACharger.exe’ inside // ‘NewDomain’ and then execute it. newDomain.ExecuteAssembly( “AssemblyToLoad.exe” ); // Unload the new domain. AppDomain.Unload( newDomain ); } } This example will display the following: Thread:MyThread Calling ExecuteAssembly() from appdomain AssemblyLoader.exe Thread:MyThread Hi from the domain: NewDomain Note the need to add “file:///” to specify that the assembly is located on a local storage device. If this was not the case, we could have used “http:///” to load the assembly from the web. This example also illustrates that the default name for an AppDomain is the name of the main module from the launched assembly (in this case, AssemblyLoader.exe). Running some code inside the context of another AppDomain Thanks to the instance method AppDomain.DoCallBack() you have the possibility of executing code of the assembly within the current AppDomain in the context of another application domain. For this, the code must be contained within a method which will be ref- erenced through a System.CrossAppDomainDelegate delegate. The process is illustrated with the following example: Example 4-4 using System; using System.Threading; public class Program { public static void Main() { Thread.CurrentThread.Name = “MyThread”; AppDomain newDomain = AppDomain.CreateDomain( “NewDomain” ); CrossAppDomainDelegate deleg = new CrossAppDomainDelegate(Fct); newDomain.DoCallBack(deleg); AppDomain.Unload( newDomain ); } public static void Fct() { Console.WriteLine( “Thread:{0} execute Fct() inside the appdomain {1}”, Thread.CurrentThread.Name, AppDomain.CurrentDomain.FriendlyName); } } This example displays the following: Thread:MyThread