Datasheet

One important aspect of garbage collection is that it is not deterministic. In other words, you cannot

guarantee when the garbage collector will be called; it will be called when the CLR decides that it is

needed (unless you explicitly call the collector), though it is also possible to override this process and

call up the garbage collector in your code.

Security

.NET can really excel in terms of complementing the security mechanisms provided by Windows

because it can offer code-based security, whereas Windows only really offers role-based security.

Role-based security is based on the identity of the account under which the process is running (that is, who

owns and is running the process). Code-based security on the other hand is based on what the code

actually does and on how much the code is trusted. Thanks to the strong type safety of IL, the CLR is able

to inspect code before running it in order to determine required security permissions. .NET also offers a

mechanism by which code can indicate in advance what security permissions it will require to run.

The importance of code-based security is that it reduces the risks associated with running code of dubious

origin (such as code that you’ve downloaded from the Internet). For example, even if code is running

under the administrator account, it is possible to use code-based security to indicate that that code

should still not be permitted to perform certain types of operation that the administrator account would

normally be allowed to do, such as read or write to environment variables, read or write to the registry,

or access the .NET reflection features.

Security issues are covered in more depth in Chapter 16, “.NET Security.”

Application domains

Application domains are an important innovation in .NET and are designed to ease the overhead

involved when running applications that need to be isolated from each other, but that also need to be

able to communicate with each other. The classic example of this is a Web server application, which may

be simultaneously responding to a number of browser requests. It will, therefore, probably have a num-

ber of instances of the component responsible for servicing those requests running simultaneously.

In pre-.NET days, the choice would be between allowing those instances to share a process, with the

resultant risk of a problem in one running instance bringing the whole Web site down, or isolating those

instances in separate processes, with the associated performance overhead.

Up until now, the only means of isolating code has been through processes. When you start a new appli-

cation, it runs within the context of a process. Windows isolates processes from each other through

address spaces. The idea is that each process has available 4GB of virtual memory in which to store its

data and executable code (4GB is for 32-bit systems; 64-bit systems use more memory). Windows

imposes an extra level of indirection by which this virtual memory maps into a particular area of actual

physical memory or disk space. Each process gets a different mapping, with no overlap between the

actual physical memories that the blocks of virtual address space map to (see Figure 1-2).

Chapter 1

05_575341 ch01.qxd 10/4/05 7:03 PM Page 14