In DotNetNuke v 4.6 a new installer system was introduced to handle the new Authentication Systems.  In DotNetNuke 5.0 we have extended the use of the Installer to all extensions, including Modules, Language Packs and Skins.  In previous blogs in this series I introduced the new Extension Installer Manifest, and the 3 components that most developers would be fairly familiar with – Module, Assembly, File, as they are similar to the legacy module manifest.

In this article I will begin to dive deeper into some of the other components, by looking at the Cleanup Component.

For quite a few versions, the core DotNetNuke installer has used the concept of a cleanup file which lists the files and folders that are no longer being used.  This cleanup file is a simple text file eg. 04.09.00.txt is the cleanup file to cleanup files that are no longer used in version 4.9 of the core (see Listing 1).

' Remove uninstalled module packages that have new versions in distribution. 

Install\Module\Forum_03.20.09_Install.resources 

Install\Module\HTML_04.06.01_Install.zip

More recently, the same concept was introduced into the legacy Module Installer.  Again the convention was used that the cleanup file would be named “version".txt (eg 02.00.00.txt).  This convention required Module developers to include a SqlDataProvider file for each version, regardless of whether there were any changes, as the only way that the legacy installer was aware of a "new" version was whether there was a script file to process.

In the new Extension Installer manifest operations must be explicitly declared, and so there is a Cleanup Component Installer (see Listing 2).

   1:  <component type="Cleanup" version="05.00.00">

   2:      <files>

   3:          <file>

   4:              <path>bin</path>

   5:              <name>DotNetNuke.Caching.BroadcastPollingCachingProvider.dll</name>

   6:          </file>

   7:      </files>

   8:  </component>

Those of you who have read the previous blog post will notice that this components schema is very similar to the schema for the File component.  (Actually many of the other component manifest schema are similar to the File component and this is demonstrated by the fact that the Coponent Installer classes sub-class the FileInstaller component).

If you have a lot of files to remove the new Cleanup Component provides an alternative method similar to the legacy method.  If the fileName attribute is specified the Cleanup component uses an external file.

   1:  <component type="Cleanup" version="05.00.00" fileName="05.00.00.txt" />

While you can use a cleanup file in the same way as the legacy installer, there is still one difference.  Unlike the legacy installer which uses a file naming convention and requires you to have a script file with the same version number, the Cleanup Component requires you to explicitly reference the file, the name can be anything you want, and there is no requirement for a script file with the same version number.

This article was originally posted on my dotnetnuke.com Blog.  I have edited it slightly.

In my previous blog (Part 1) of this series of Blogs about "Understanding the manifest" used in the new Extension Installer, I introduced the overall 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 focusing in this blog on the "components" are of the manifest, lets look at the components node in detail.

This example is for a simple "HelloWorld" module.  You will notice that we have 3 components.  Most package types will include a component that is specific 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: More accurately 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 explicitly.  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.

This article was originally posted on my dotnetnuke.com Blog.  I have edited it slightly.

DotNetNuke 5.0 includes a new "Unified Extension/Package Installer".  In previous articles on my dotnetnuke.com blog I have discussed this new installer, in particular with respect to how it is used.  In this blog I will start to introduce developers to the new manifest that drives the new Installation System.

The concept of the new Installer can be summed up as follows:

• Provide a manifest driven installation - in this case configuration over convention
• Provide a single "unified" manifest applicable to all extension types - modules/skins/languages
• Provide a "component" based installer - a files component for modules can be reused in installing skins or languages files
• Provide extension points for developers to take advantage of the new system.

So lets dive in to the new manifest and see what is going on.

This is the basic outline of an extension manifest.  In this example we see the outline of the manifest for the Broadcast Polling Caching Provider.

The first line identifies this as a "Package" manifest, and it is a version 5.0 manifest.  This is used by the Installer to identify it as a "new" manifest, and process it accordingly.  The installer, will also recognize legacy manifests, and translate the manifests to the new system.

The architecture of the installer (and the manifest) allows for the installation of multiple packages in one zip archive and this is shown by the use of the packages and package nodes.  A package node has a number of attributes and child nodes.  While these may be fairly obvious, I will briefly explain each one:

• package - the parent node for a "package"
  • name - a Unique name for the package
  • type - the type of package/extension - eg Module, Skin, Container, Provider, SkinObject etc
  • version - the version of the package
• friendlyName - a friendly name for the package
• description - a description of the package
• owner - the owner of the package
  • name - the name of the owner
  • organization - the organization that owns/created the package
  • url - A url to the owner's website
  • email - A support email address for communicating with the owner
• license - the license for the package - the license text can either be embedded in the manifest - or in an external file
  • src - the location of the license text - if in an external file
• releaseNotes - release Notes for this version of the package (as with the license the text can be embedded in the manifest - or in an external file)
  • src - the location of the release notes - if in an external file
• dependencies - this section describes dependencies that the package expects - I will go into more detain on this in a future blog - but dependencies can be core version, another package (for example a German Language Pack for the Links module has a dependency on the Links module being installed AND a dependency on the German core language being installed)
• components - a list of components that are in this package.  As with dependencies I will go into this in a future blog - but as an example this package actually contains 5 components - an assembly component, a files component, a database script component, a config component for updating web.config and a file cleanup component.

The benefit of this common approach is that all extensions can benefit from the same kind of features we have come to expect from modules.  In addition, we have added a number of new features, definition of the owner/author of the package, inclusion of a license - that the user must explicitly agree to on installation, inclusion of release notes, an extensible dependency framework and an extensible component architecture.

In my next blog on this subject I will delve into the common "components" that make up an Extension package.