Assembly metadata is stored in Manifest.Manifest contains all the metadata needed to do the
following things
1.Version of assembly
2.Security identity
3.Scope of the assembly
4.resolve references to resources and classes.
5The assembly manifest can be stored in either a PE file (an .exe or .dll) with
Microsoft intermediate language (MSIL) code or in a stand-alone PE file that
contains only assembly manifest information.
Strong name is similar to GUID(It is supposed to be unique in space and time) in COM
components.Strong Name is only needed when we need to deploy assembly in GAC.Strong
Names helps GAC to differentiate between two versions.Strong names use public key cryptography(PKC) to ensure that no one can spoof it.
.............................................................................................................................................................
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 (Portable Executable) file (an .exe or .dll) with Microsoft intermediate language (MSIL) code or in a standalone PE (Portable Executable) file that contains only assembly manifest information.
The following table shows the information contained in the assembly manifest. The first four items — the assembly name, version number, culture, and strong name information — make up the assembly's identity.
Assembly name: A text string specifying the assembly's name.
Version number: A major and minor version number, and a revision and build number. The common language runtime uses these numbers to enforce version policy.
Culture: Information on the culture or language the assembly supports. This information should be used only to designate an assembly as a satellite assembly containing culture- or language-specific information. (An assembly with culture information is automatically assumed to be a satellite assembly.)
Strong name information: The public key from the publisher if the assembly has been given a strong name.
List of all files in the assembly: A hash of each file contained in the assembly and a file name. Note that all files that make up the assembly must be in the same directory as the file containing the assembly manifest.
Type reference information: Information used by the runtime to map a type reference to the file that contains its declaration and implementation. This is used for types that are exported from the assembly.
Information on referenced assemblies: A list of other assemblies that are statically referenced by the assembly. Each reference includes the dependent assembly's name, assembly metadata (version, culture, operating system, and so on), and public key, if the assembly is strong named.
...........................................................................................................................................
following things
1.Version of assembly
2.Security identity
3.Scope of the assembly
4.resolve references to resources and classes.
5The assembly manifest can be stored in either a PE file (an .exe or .dll) with
Microsoft intermediate language (MSIL) code or in a stand-alone PE file that
contains only assembly manifest information.
Strong name is similar to GUID(It is supposed to be unique in space and time) in COM
components.Strong Name is only needed when we need to deploy assembly in GAC.Strong
Names helps GAC to differentiate between two versions.Strong names use public key cryptography(PKC) to ensure that no one can spoof it.
.............................................................................................................................................................
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 (Portable Executable) file (an .exe or .dll) with Microsoft intermediate language (MSIL) code or in a standalone PE (Portable Executable) file that contains only assembly manifest information.
The following table shows the information contained in the assembly manifest. The first four items — the assembly name, version number, culture, and strong name information — make up the assembly's identity.
Assembly name: A text string specifying the assembly's name.
Version number: A major and minor version number, and a revision and build number. The common language runtime uses these numbers to enforce version policy.
Culture: Information on the culture or language the assembly supports. This information should be used only to designate an assembly as a satellite assembly containing culture- or language-specific information. (An assembly with culture information is automatically assumed to be a satellite assembly.)
Strong name information: The public key from the publisher if the assembly has been given a strong name.
List of all files in the assembly: A hash of each file contained in the assembly and a file name. Note that all files that make up the assembly must be in the same directory as the file containing the assembly manifest.
Type reference information: Information used by the runtime to map a type reference to the file that contains its declaration and implementation. This is used for types that are exported from the assembly.
Information on referenced assemblies: A list of other assemblies that are statically referenced by the assembly. Each reference includes the dependent assembly's name, assembly metadata (version, culture, operating system, and so on), and public key, if the assembly is strong named.
...........................................................................................................................................
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 (Portable Executable) file (an .exe or .dll)
with Microsoft intermediate language (MSIL) code or in a standalone PE (Portable Executable) file that contains only assembly manifest information. The following table shows the information contained in the assembly manifest. The first four items - the assembly name, version number, culture, and strong name information - make up the assembly's identity.
Assembly name: A text string specifying the assembly's name. Version number: A major and minor version number, and a revision and build number. The common language runtime uses these numbers to enforce version policy.
Culture: Information on the culture or language the assembly supports. This information should be used only to designate an assembly as a satellite assembly containing culture- or languagespecific information. (An assembly with culture information is automatically assumed to be a satellite assembly.) Strong name information: The public key from the publisher if the assembly has been given a strong name. List of all files in the assembly: A hash of each file contained in the assembly and a file name. Note that all files that make up the assembly must be in the same directory as the file containing the assembly manifest. Type reference information: Information used by the runtime to map a type reference to the file that contains its declaration and implementation. This is used for types that are exported from the assembly.
Information on referenced assemblies: A list of other assemblies that are statically referenced by the assembly. Each reference includes the dependent assembly's name, assembly metadata (version, culture, operating system, and so on), and public key, if the assembly is strong named.
..................................................................................................................................................................
Posts
0 comments:
Post a Comment