When we launch the Notepad program in Windows,
the program executes inside of a container known as a process. We can launch
multiple instances of Notepad, and each instance will run in a dedicated
process. Using the Task Manager application, we can see a list of all processes
currently executing in the system.
A process contains the executable code and
data of a program inside memory it has reserved from the operating system.
There will be at least one thread executing instructions inside of the process,
and in most cases there are multiple threads. If the program opens any files or
other resources, those resources will belong to the process.
A process is also boundary. Erroneous code inside
of a process cannot corrupt areas outside of the current process. It is easy to
communicate inside of a process, but special techniques are required to
communicate from one process to another. Each process also runs under a
specific security context which can dictate what the process can do on the
machine and network.
A process is the smallest unit of isolation
available on the Windows operating system. This could pose a problem for an ISP
who wants to host hundreds of ASP.NET applications on a single server. The ISP
will want to isolate each ASP.NET application to prevent one application from
interfering with another company’s application on the same server, but the
relative cost of launching and executing a process for hundreds of
applications may be prohibitive.
Introducing the Application Domain
.NET introduces the concept of an application
domain, or AppDomain. Like a process, the AppDomain is both a container and a boundary. The .NET
runtime uses an AppDomain as a container for code and
data, just like the operating system uses a process as a container for code and
data. As the operating system uses a process to isolate misbehaving code,
the .NET runtime uses an AppDomain to isolate code
inside of a secure boundary.
An AppDomain belongs to
only a single process, but single process can hold multiple AppDomains.
An AppDomain is relatively cheap to create (compared
to a process), and has relatively less overhead to maintain than a process. For
these reasons, an AppDomain is a great solution for
the ISP who is hosting hundreds of applications. Each application can exist
inside an isolated AppDomain, and many of these AppDomains can exist inside of a single process – a cost
AppDomains And You
You’ve created two ASP.NET applications on the
same server, and have not done any special configuration. What is happening?
A single ASP.NET worker process will host both of
the ASP.NET applications. On Windows XP and Windows 2000 this process is named
aspnet_wp.exe, and the process runs under the security context of the local
ASPNET account. On Windows 2003 the worker process has the name w3wp.exe and
runs under the NETWORK SERVICE account by default.
An object lives in one AppDomain.
Each ASP.NET application will have it’s own set of
global variables: Cache, Application, and Session objects are not shared. Even
though the code for both of the applications resides inside the same process,
the unit of isolation is the .NET AppDomain. If there
are classes with shared or static members, and those classes exist in both
applications, each AppDomain will have it’s own copy of the static fields – the data is not shared.
The code and data for each application is safely isolated and inside of a
boundary provided by the AppDomain
In order to communicate or pass objects between AppDomains, you’ll need to look at techniques in .NET for
communication across boundaries, such as .NET remoting
or web services.
The one caveat to the idea of an AppDomain as a boundary is that ASP.NET applications will
run with full trust by default. Fully trusted code can execute native code, and
native code can essentially have access to anything inside the process.
You’ll need to run applications with partial trust to restrict access to unmanged code and verify all managed code to secure AppDomains.
Shadow Copies and Restarts
Once an assembly is loaded into an AppDomain, there is no way to remove the assembly from the AppDomain. It is possible, however, to remove an AppDomain from a process.
If you copy an updated dll into an application’s
bin subdirectory, the ASP.NET runtime recognizes there is new code to execute.
Since ASP.NET cannot swap the dll into the existing AppDomain , it starts a new AppDomain. The old application domain is “drain stopped”,
that is, existing requests are allowed to finish executing, and once they are
all finished the AppDomain can unload. The new AppDomain starts with the new code and begins taking all
Typically, when a dll loads into a process, the
process locks the dll and you cannot overwrite the file on disk. However, AppDomains have a feature known as Shadow Copy that allows
assemblies to remain unlocked and replaceable on disk.
The runtime initializes ASP.NET with Shadow Copy
enabled for the bin directory. The AppDomain will
copy any dll it needs from the bin directory to a temporary location before
locking and loading the dll into memory. Shadow Copy allows us to
overwrite any dll in the bin directory during an update without taking the web
Master Of Your Domain
Application domains replace the OS process as the
unit of isolation for .NET code. An understanding of application domains
will give you an idea of the work taking place behind the scenes of an ASP.NET
application. Using the CurrentDomain property of the AppDomain class you can inspect properties about the AppDomain your code is executing in, including the Shadow
Copy settings we discussed in this article.
UVN Pardha Saradhi