Datasheet

Shared Assemblies
Shared assemblies are intended to be common libraries that any other application can use. Because any
other software can access a shared assembly, more precautions need to be taken against the following
risks:
❑ Name collisions, where another company’s shared assembly implements types that have the
same names as those in your shared assembly. Because client code can theoretically have access
to both assemblies simultaneously, this could be a serious problem.
❑ The risk of an assembly being overwritten by a different version of the same assembly — the
new version being incompatible with some existing client code.
The solution to these problems involves placing shared assemblies in a special directory subtree in the
file system, known as the global assembly cache (GAC). Unlike with private assemblies, this cannot be
done by simply copying the assembly into the appropriate folder— it needs to be specifically installed
into the cache. This process can be performed by a number of .NET utilities and involves carrying out
certain checks on the assembly, as well as setting up a small folder hierarchy within the assembly cache
that is used to ensure assembly integrity.
To avoid the risk of name collisions, shared assemblies are given a name based on private key cryptogra-
phy (private assemblies are simply given the same name as their main file name). This name is known
as a strong name, is guaranteed to be unique, and must be quoted by applications that reference a shared
assembly.
Problems associated with the risk of overwriting an assembly are addressed by specifying version infor-
mation in the assembly manifest and by allowing side-by-side installations.
Reflection
Because assemblies store metadata, including details of all the types and members of these types that are
defined in the assembly, it is possible to access this metadata programmatically. Full details of this are
given in Chapter 11, “Reflection.” This technique, known as reflection, raises interesting possibilities,
because it means that managed code can actually examine other managed code, or can even examine
itself, to determine information about that code. This is most commonly used to obtain the details of
attributes, although you can also use reflection, among other purposes, as an indirect way of instantiat-
ing classes or calling methods, given the names of those classes on methods as strings. In this way, you
could select classes to instantiate methods to call at runtime, rather than compile time, based on user
input (dynamic binding).
.NET Framework Classes
Perhaps one of the biggest benefits of writing managed code, at least from a developer’s point of view, is
that you get to use the .NET base class library.
The .NET base classes are a massive collection of managed code classes that allow you to do almost any
of the tasks that were previously available through the Windows API. These classes follow the same
object model IL uses, based on single inheritance. This means that you can either instantiate objects of
whichever .NET base class is appropriate, or you can derive your own classes from them.
19
.NET Architecture
05_575341 ch01.qxd 10/4/05 7:03 PM Page 19