Datasheet

objects that are not referred to are deemed to be no longer accessible from your code and can therefore
be removed. Java uses a system of garbage collection similar to this.
Garbage collection works in .NET because IL has been designed to facilitate the process. The principle
requires that you cannot get references to existing objects other than by copying existing references and
that IL be type safe. In this context, what we mean is that if any reference to an object exists, then there is
sufficient information in the reference to exactly determine the type of the object.
It would not be possible to use the garbage collection mechanism with a language such as unmanaged
C++, for example, because C++ allows pointers to be freely cast between types.
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 actu-
ally 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 nor-
mally 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 19, “.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
14
Part I: The C# Language
24727c01.qxd:WroxPro 5/7/07 12:12 PM Page 14