2.4 Application Domains

only for RuBoard

In an unmanaged Windows environment, applications are isolated from one another by process boundaries. As shown in Figure 2-1, each Win32 program is given its own process and a 4 GB virtual address space to go along with it. Additional libraries or components share this address space with their client. The operating system handles all the work associated with mapping the virtual address space to an actual address in memory. The advantage of this isolation is that if a program crashes, it won't take the entire system downjust the current process.

Figure 2-1. The Win32 process boundary

Under .NET, the CLR manages the memory; Windows doesn't give it to you directly. One reason for this is garbage collection. The CLR needs to know where memory is located to free it or determine if it is in use at all, which is why no pointers are allowed in managed code. This level of indirection, in regard to memory, allows the CLR to provide application isolation with more granularity. In .NET, an entity called an application domain determines isolation.

Managed Versus Unmanaged Code

The term managed code refers to code compiled under the .NET Framework. The framework automatically manages the lifetime of an object, hence the term. Unmanaged code is simply all other code running outside of the bounds of .NET.

As shown in Figure 2-2, several application domains can exist within the same process and still remain isolated from one another. They can also be loaded and unloaded independently of the process, which means that if a crash occurs, the offending application domain can be unloaded without affecting the entire process. This is highly efficient, considering the amount of overhead involved in creating a process.

Figure 2-2. Application domains provide isolation for .NET applications within a process.

Application domains do not share the same restrictions as a process. They can contain any number of EXEs or DLLs in several combinations. Typically, though, an application is loaded into one application domain. This is the case with hello-client.exe and hello.dll . In fact, you can verify this yourself with the CLR shell debugger. In a console window, run hello-client.exe . Spawn a second console and start up the debugger from the command line like this:

 C:>cordbg 

Once the debugger is running, you can issue a pro command to get information on all managed .NET applications that are running on the system. It will look similar to this:

 C:\>cordbg Microsoft (R) Common Language Runtime Test Debugger Shell  Version 1.0.3705.0 Copyright (C) Microsoft Corporation 1998-2001.  All rights reserved.     (cordbg) pro  PID=0x818 (2072)  Name=C:\hello-client.exe   ID=1  AppDomainName= hello-client.exe  PID=0x6c0 (1728)  Name=C:\WINNT\Microsoft.NET\Framework\v1.0.3705\aspnet_wp.exe         ID=8  AppDomainName=/LM/w3svc/1/root/eyeofnet-7-126592112951200512         ID=7  AppDomainName=/LM/W3SVC/1/ROOT-6-126592112840541392         ID=6  AppDomainName=/LM/W3SVC/1/Root/oowd-5-126591711176576976         ID=5  AppDomainName=/LM/w3svc/3/root/eyeofnet-4-126591677652271392         ID=4  AppDomainName=/LM/W3SVC/3/Root-3-126591677517878144         ID=1  AppDomainName=DefaultDomain 

Loading hello-client.exe and hello.dll into two different application domains is possible. But exotic configurations such as this require additional code. The hello client would have to create the assembly dynamically and load the hello component into it. Calls between the two executables would require remoting across the application domain boundaries, which is very similar to the behavior of an out-of-process COM server.

only for RuBoard