Datasheet

self-descriptive. You need no other information to use an assembly, meaning that you avoid situations
such as failing to add required data to the system registry and so on, which was often a problem when
developing with other platforms.
This means that deploying applications is often as simple as copying the files into a directory on a remote
computer. Since no additional information is required on the target systems, you can just run an executable
file from this directory and (assuming the .NET CLR is installed) away you go.
Of course, you won’t necessarily want to include everything required to run an application in one place.
You might write some code that performs tasks required by multiple applications. In situations like this, it
is often useful to place this reusable code in a place accessible to all applications. In the .NET Framework,
this is the Global Assembly Cache (GAC). Placing code in this cache is simple — you just place the assembly
containing the code in the directory containing this cache.
Managed Code
The role of the CLR doesn’t end once you have compiled your code to MSIL, and a JIT compiler has
compiled this to native code. Code written using the .NET Framework is managed when it is executed
(this stage is usually referred to as being at runtime). This means that the CLR looks after your applica-
tions by managing memory, handling security, allowing cross-language debugging, and so on. By con-
trast, applications that do not run under the control of the CLR are said to be unmanaged and certain
languages such as C++ can be used to write such applications that, for example, access low-level func-
tions of the operating system. However, in C# you can write only code that runs in a managed environ-
ment. You will make use of the managed features of the CLR and allow .NET itself to handle any
interaction with the operating system.
Garbage Collection
One of the most important features of managed code is the concept of garbage collection. This is the .NET
method of making sure that the memory used by an application is freed up completely when the appli-
cation is no longer in use. Prior to .NET this has mostly been the responsibility of programmers, and a
few simple errors in code could result in large blocks of memory mysteriously disappearing as a result
of being allocated to the wrong place in memory. This usually meant a progressive slowdown of your
computer followed by a system crash.
.NET garbage collection works by inspecting the memory of your computer every so often and removing
anything from it that is no longer needed. There is no set timeframe for this; it might happen thousands of
times a second, once every few seconds, or whenever, but you can rest assured that it will happen.
There are some implications for programmers here. Since this work is done for you at an unpredictable
time applications have to be designed with this in mind. Code that requires a lot of memory to run
should tidy itself up rather than waiting for garbage collection to happen, but this isn’t anything like as
tricky as it sounds.
Fitting It Together
Before moving on, I’ll summarize the steps required to create a .NET application as discussed previously:
1. Application code is written using a .NET-compatible language such as C#, as shown in Figure 1-1.
6
Chapter 1
05_578472 ch01.qxd 9/22/05 10:54 PM Page 6