PeterK
PeterK

Reputation: 6317

Difference between application manifest and assembly manifest

What is the difference between application manifest and assembly manifest? Where is each one used? Which one of the two is found in .dll or .exe resources? (or both can be there? ).

Sorry if its too many questions at once, but if anyone can explain this to me it would be really helpful. The reason i'm asking this is that i want to be able to extract information from manifests embedded in PE files. I found these descriptions of manifests, but there are two and i'm not sure which one to follow:

Application manifest description
Assembly manifest description

EDIT: and no, i do not want to use any API calls. I'm writting it all myself.

Upvotes: 3

Views: 4854

Answers (3)

staafl
staafl

Reputation: 3235

In brief, the two are completely separate concepts with unfortunately similar names.

An application manifest is an XML file embedded in, or distributed along with, a PE binary (managed or native), giving instructions to the OS loader about things such as SxS assembly dependencies, required elevation, OS version compatibility, etc.

An assembly manifest is a section in a CLI assembly, stating the managed assembly's dependencies, the files making up the assembly, the assembly's public key, type exports, CLR flags, and so on. You can inspect an assembly's manifest using ILDASM.exe or most .NET decompilers.

A relevant excerpt from ECMA 335 (the CLI specification), section I.9.6:

Manifests: Every assembly has a manifest that declares which files make up the assembly, what types are exported, and what other assemblies are required to resolve type references within the assembly. Just as CLI components are self-describing via metadata in the CLI component, so are assemblies self-describing via their manifests. When a single file makes up an assembly it contains both the metadata describing the types defined in the assembly and the metadata describing the assembly itself. When an assembly contains more than one file with metadata, each of the files describes the types defined in the file, if any, and one of these files also contains the metadata describing the assembly (including the names of the other files, their cryptographic hashes, and the types they export outside of the assembly).

Note that:

  • all managed assemblies must have assembly manifests, executables and libraries alike;
  • all native binaries, executables and libraries, may have application manifests.

Upvotes: 3

Chris Becke
Chris Becke

Reputation: 36101

Application manifests are typically embedded in EXEs and, ironically, Dlls, and specify which assemblies the EXE or DLL is dependent upon.

Assembly manifests can be embedded in DLLs, or be on disk as a separate file, and give an assembly an identity, and a list of resources: being dll's, activation free com objects, and window classes.

If the name of the assembly is the name of a dll, then the same manifest ends up being used as both an application manifest to determine the dependencies of the dll, and an assembly manifest to see what the assembly exports. This option really just seems crazy for native assemblies, its usually better to create an assembly with a complicated name along the lines of company.product.module, and then just have a simple module.dll as its one entry.

Upvotes: 1

PeterK
PeterK

Reputation: 6317

It seems that i will have to follow both:

As a resource in a DLL, the assembly is available for the private use of the DLL. An assembly manifest cannot be included as a resource in an EXE. An EXE file may include an application manifest as a resource.

(Information found here). So it seems that executables have application manifests embedded in resources and libraries (DLL) have assembly manifests. Since both of them are PE (portable executable), i will need to parse both types.

Upvotes: 1

Related Questions