This article is cross-posted from my personal blog.
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).
Listing 1 - The File Component manifest fragment from the FileBasedCachingProvider
1: <component type="File">
Most of the components which handle files inherit from the base File Component. The
element is used to identify a base (or root) path for all the files identified. Each element has a and
which is combined with this base path to identify the file completely. The element also has a 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 and 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 and
, there are two other elements that are defined in File component but have no effect in the base class.
- is used by the Assembly Installer to determine whether the assembly should be added or removed
- 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.