In my previous blog (Part 1) of this series of Blogs about "Understanding the manifest" used in the new Extension Installer, I introduced the overal design of the new Installer manifest. In this blog I will delve more deeply into the "components" area of the manifest.
As with my first blog lets look at an example. As we are focussing in ths blog on the "components" are of the manifest, lets look at the components node in detail.
Ths example is for a simple "HelloWorld" module. You will notice that we have 3 components. Most package types will include a component that is specfic for that type. Thus Module packages contain a Module component, Skin packages will contain a Skin component. So this HelloWorld module contains 3 components - a Module component, an Assembly component and a File component.
Module developers will see some similarity here to the legacy Module manifest. The main difference here, is that the assemblies and files are moved into their own component. This allows us to use the same FileInstaller for all extension types - not just modules So lets review the 3 components.
Module Component
The module component is used to define the module registration information. It starts with a "desktopModule" node. If you look carefully at the structure of the "desktopModule" node - you will notice that there is essentially a 1:1 mapping with the properties of the DesktopModuleInfo class (and its child objects).
This is intentional - the Module Component Installer reads the xml from the manifest - and uses Xml Serialization to deserialize the xml into a DesktopModuleInfo instance which is then persisted to the database. Conversely, when creating the package using the built "Package Creation Wizard" the module component manifest is created by serializing the DesktopModuleInfo instance.
(Note: For accuracy it uses the IXmlSerializable interface - the XmlSerializer class itself is not very performant due to all the reflection it has to use)
File Component
This section of the manifest is very similar in structure to the "files" element of the legacy Module manifest, with one major addition - the new "basePath" child element. In the module manifest the files element was processed based on the assumption that all the files should be copied to the "DesktopModules\FolderName" folder. As this component is now used by mutiple package types, we need to identify the base location for the files. This also allows developers of multiple extensions to load files into a common area for use by all of the extensions, as they can include more than one File component in the manifest - each with a different basePath.
Assembly Component
In the legacy Module manifest an assembly was included in the "files" element. The installer made an assumption that a file with a ".dll" extension was an assembly and copy it into the \bin folder.
The Assembly component handles assemblies explictly. As the AssemblyInstaller class inherits from the FileInstaller class, its manifest structure is similar to the File Components manifest structure.
I used this Hello World example as it is quite straightforward and does not really introduce any new concepts - modules already managed "Module Registration" and copying of files and assemblies. In my next blog we will look at some of the other component installers.