Manifest Based
Application
This feature
provides new support for loading and activating applications through the use of
a manifest. Manifest-based activation is essential for supporting ClickOnce
applications. Traditionally, applications are activated through a reference to
an assembly that contains the application's entry point. For example, clicking
an application's .exe file from within the Windows shell causes the shell to
load the common language runtime (CLR) and call a well-known entry point within
that .exe file's assembly.
The manifest-based activation model uses an application manifest for activation
rather than an assembly. A manifest fully describes the application, its
dependencies, security requirements, and so forth. The manifest model has several
advantages over the assembly-based activation model, especially for Web
applications. For example, the manifest contains the security requirements of
the application, which enables the user to decide whether to allow the
application to execute before downloading the code. The manifest also contains
information about the application dependencies.
Manifest-based activation is provided by a set of APIs that allow managed hosts
to activate applications and add-ins described by a manifest. These APIs contain
a mixture of both new classes and extensions to existing classes.
This activation model also invokes an entity called a Trust Manager that
performs the following tasks:
Determines whether an application is allowed to be activated. This decision can
be made by prompting the user, querying policy, or by any other means deemed
appropriate for a given Trust Manager.
Sets up the security context to run an application in. Most commonly, this step
involves setting up a code access security (CAS) policy tree on the application
domain in which the application will run.
This activation model also invokes an entity called a Trust
Manager that performs the following tasks:
1.
Determines
whether an application is allowed to be activated. This decision can be made by
prompting the user, querying policy, or by any other means deemed appropriate
for a given Trust Manager.
2.
Sets
up the security context to run an application in. Most commonly, this step
involves setting up a code access security (CAS) policy tree on the application
domain in which the application will run.
.NET Framework Developer's Guide
Assembly Manifest
Every assembly,
whether static or dynamic, contains a collection of data that
describes how the elements in the assembly relate to each other. The assembly
manifest contains this assembly metadata. An assembly manifest contains all the
metadata needed to specify the assembly's version requirements and security
identity, and all metadata needed to define the scope of the assembly and
resolve references to resources and classes. The assembly manifest can be
stored in either a PE file (an .exe or .dll) with Microsoft intermediate
language (MSIL) code or in a standalone PE file that contains only assembly
manifest information.
The following illustration shows the different ways the manifest
can be stored.
Types of assemblies
![]()
For an assembly with one associated file, the manifest is
incorporated into the PE file to form a single-file assembly. You can create a
multifile assembly with a standalone manifest file or with the manifest
incorporated into one of the PE files in the assembly.
Each assembly's manifest performs the following functions:
- Enumerates the files
that make up the assembly.
- Governs how
references to the assembly's types and resources map to the files that
contain their declarations and implementations.
- Enumerates other
assemblies on which the assembly depends.
- Provides a level of
indirection between consumers of the assembly and the assembly's
implementation details.
- Renders the assembly
self-describing.
Visit my blog :
www.dotnetask.blog.co.in