Runtime Technical Questions
Assemblies
What is an assembly?
An assembly is the primary building block of a .NET Framework
application. It is a collection of functionality that is built,
versioned, and deployed as a single implementation unit (as one
or more files). All managed types and resources are marked
either as accessible only within their implementation unit, or
as accessible by code outside that unit.
Assemblies are self-describing by means of their manifest, which
is an integral part of every assembly. The manifest:
Establishes the assembly identity (in the form of a text name),
version, culture, and digital signature (if the assembly is to
be shared across applications).
Defines what files (by name and file hash) make up the assembly
implementation.
Specifies the types and resources that make up the assembly,
including which are exported from the assembly.
Itemizes the compile-time dependencies on other assemblies.
Specifies the set of permissions required for the assembly to
run properly.
This information is used at run time to resolve references,
enforce version binding policy, and validate the integrity of
loaded assemblies. The runtime can determine and locate the
assembly for any running object, since every type is loaded in
the context of an assembly. Assemblies are also the unit at
which code access security permissions are applied. The identity
evidence for each assembly is considered separately when
determining what permissions to grant the code it contains.
The self-describing nature of assemblies also helps makes
zero-impact install and XCOPY deployment feasible.
What are private assemblies and shared assemblies?
A private assembly is used only by a single application, and
is stored in that application's install directory (or a
subdirectory therein). A shared assembly is one that can be
referenced by more than one application. In order to share an
assembly, the assembly must be explicitly built for this purpose
by giving it a cryptographically strong name (referred to as a
strong name). By contrast, a private assembly name need only be
unique within the application that uses it.
By making a distinction between private and shared assemblies,
we introduce the notion of sharing as an explicit decision.
Simply by deploying private assemblies to an application
directory, you can guarantee that that application will run only
with the bits it was built and deployed with. References to
private assemblies will only be resolved locally to the private
application directory.
There are several reasons you may elect to build and use shared
assemblies, such as the ability to express version policy. The
fact that shared assemblies have a cryptographically strong name
means that only the author of the assembly has the key to
produce a new version of that assembly. Thus, if you make a
policy statement that says you want to accept a new version of
an assembly, you can have some confidence that version updates
will be controlled and verified by the author. Otherwise, you
don't have to accept them.
For locally installed applications, a shared assembly is
typically explicitly installed into the global assembly cache (a
local cache of assemblies maintained by the .NET Framework). Key
to the version management features of the .NET Framework is that
downloaded code does not affect the execution of locally
installed applications. Downloaded code is put in a special
download cache and is not globally available on the machine even
if some of the downloaded components are built as shared
assemblies.
The classes that ship with the .NET Framework are all built as
shared assemblies.
|
