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, and I began to detail the individual component manifests by describing the Cleanup Component and the Assembly Component and File Component.

In this article I will dive deeper into the Script Component (see Listing 1).

   1:  <component type="Script">

   2:    <scripts>

   3:      <basePath>Providers/CachingProviders/BroadcastPollingCachingProvider</basePath>

   4:      <script type="Install">

   5:        <path>Install</path>

   6:        <name>Install.SqlDataProvider</name>

   7:        <version>05.00.00</version>

   8:      </script>

   9:      <script type="UnInstall">

  10:        <path>UnInstall</path>

  11:        <name>UnInstall.SqlDataProvider</name>

  12:        <version>05.00.00</version>

  13:      </script>

  14:    </scripts>

  15:  </component>

The Script component is another Installer that inherits from the base File Component.  The <basePath> element identifies the root location for the Script.  It uses the <scripts> and <script> elements in place of the base class <files> and <file> element.

Note that there a few enhancements (compared with the legacy Module Installer) in how scripts are handled.

1. Each script has a “type” attribute, which identifies whether the Script should be used in Install/Upgrade mode or is used 'in “UnInstall” mode
2. Each script has a required version element which identifies which version the script corresponds to.  This means that you no longer have to use the convention of naming the script with the version “xx.xx.xx.SqlDataProvider”.  ou can of course still use the legacy naming convention, but you are not required to.
3. The installer does support the “Install.SqlDataProvider” special script which is run first when installing an Extension.

Last week my Dell XPS M1330 laptop died.

After searching the internet I discovered that the problem was a faulty NVidea graphics card, which was quite a well-known problem. 

On Thursday, I called Dell’s Canadian XPS Customer Support line and the representative immediately recognised the problem and arranged to have a box shipped to me so I could pack it up and send it to their Canadian Service Centre in Newmarket, Ontario.

The box arrived Friday morning, and I packed the laptop into it and dropped it off at the local Purolator office in Langley.

Yesterday, I was surprised when a Purolator delivery man knocked on my door with my laptop, and its running great now!!

So Kudos to Dell, who expedited this repair taking 4 business days to ship a box 3 times across the country as well as repairing my computer.

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, and I began to detail the individual component manifests by describing the Cleanup Component and the Assembly Component.

In this article I will dive deeper into the File Component (see Listing 1).

   1:  <component type="File">

   2:    <files>

   3:      <basePath>Providers\CachingProviders\FileBasedCachingProvider</basePath>

   4:      <file>

   5:        <name>license.txt</name>

   6:      </file>

   7:      <file>

   8:        <name>releaseNotes.txt</name>

   9:      </file>

  10:    </files>

  11:  </component>

Most of the components which handle files inherit from the base File Component.  The <basePath> element is used to identify a base (or root) path for all the files identified.  Each <file> element has a <name> and <path> which is combined with this base path to identify the file completely.  The <file> element also has a <sourceFileName> element.  This is used to identify the file’s location within the zip file, if different from the file location in the destination.

The component installers that inherit from the File Installer essentially have the same general structure – they use different names for the <file> and <files> nodes, but in most respects are the same.  They use the base class’s logic to manage the file copying etc. implementing only the custom behaviour they need.

In addition to <name> and <path>, there are two other elements that are defined in File component but have no effect in the base class.

• <action> is used by the Assembly Installer to determine whether the assembly should be added or removed
• <version> is used by both the Assembly Installer and the Script Installer

Backup and Restore

As the new Installer supports a limited rollback model, the File Installer will backup existing files before copying a new copy during Upgrade.  If there is a failure in some other component, the backups will be copied back to their original location, so the old version of the file is still present. 

If the installation/upgrade is successful, during the commit phase the backup copy is deleted and the new file is used.