Datasheet

what software uses them. There is, therefore, less need to take security precautions because there is no
risk, for example, of some other commercial software overwriting one of your assemblies with some new
version of it (apart from the case where software is designed specifically to perform malicious damage).
There are also no problems with name collisions. If classes in your private assembly happen to have the
same name as classes in someone else’s private assembly, that doesn’t matter, because any given applica-
tion will only be able to see the one set of private assemblies.
Because a private assembly is entirely self-contained, the process of deploying it is simple. You simply
place the appropriate file(s) in the appropriate folder in the file system (no registry entries need to be
made). This process is known as zero impact (xcopy) installation.
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 cryptog -
raphy (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 12, “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).
19
Chapter 1: .NET Architecture
24727c01.qxd:WroxPro 5/7/07 12:12 PM Page 19