In a previous blog I described the new Authentication Provider system being developed for the next release of DotNetNuke. One of the challenges that arose in developing these providers was - How will we install them?
Enter - "Universal Extensible Installer".
We currently have a number of extensibility points - some of which have their own installers (Modules, Skins, Language Packs) and some of which don't (EditControls/DataTypes for the Property Editor). In addition some modules have their own extensibility points - Report Visualisers (Reports), Templates (Repository), and these modules have resorted to either build their own installer or to rely on FTP methods and manual tweaks to install.
One of the early strengths of DotNetNuke over its competitiors was support for installation of custom extensions by uploading a zip file in the application itself - no need for FTP or manual tweaks to files. As the number of extensibility points increases it has become difficualt to support this ability in a consistent and unified manner.
The new "Universal Extensible Installer" will accomplish this goal. In the next release we will be including the framework for this installer and implementing it in the new Authentication System Installer (as well as for the EditControls which currently lack an installer). At a later stage we will port the existing installers (Modules, Skins, Language Packs) to use the new system.
What is this Installer? How does it work?
Some of the technical details are beyond the scope of a simple blog post but I will summarise the features of the installer below:
- A DNN feature is a "Package"
- Packages will provide common metadata (name, type, license, company name etc)
- As all Packages have the same structure there will be a central Install.ascx page for installs, and a central UnInstall.ascx file for uninstalls
- A Package can contain a number of Components (AuthenticationSystem, Files, Assemblies, DatabaseScripts, Config chages)
- A zip file can contain multiple packages or features
- A zip file will contain a single dnn manifest file - with information about the package and each component in the package.
- The Installer will parse the zip file (as it does for modules today), and create a deep object model of Packages/Components
- Each Component type has its own dedicated Installer (derived from a ComponentInstallerBase class)
- The Installers are registered in the Lists table (similar to how EditControls are today)
- The Package Installer will identify the correct component Installer to use based on the Database entry and instantiate the appropriate Installer class - all that is required is that the installer be located in an assembly in the bin
- New Installers can be added by registering a new entry in the Database - this is the main extension point - a module developer that wishes to provide a template Installer will create the appropriate TemplateInstaller and add an entry to the Lists table (in its install script), and provide the appropriate link to the Install/UnInstall pages. Note: the Installer itself provides utility methods to build the appropriate links.
- Packages will be registered in the Database (together with the manifest for that package), fo easy uninstall
- Common Component Installers will be provided by the core (Files, Assemblies, Scripts, Config changes) for use by package installers
- Components will handle how their own data is registered.
- ComponentInstallers will need to support 4 methods (Install, UnInstall, Commit and Rollback). This will allow the Package Installer to roll back partially complete installations when a component install fails.
So the upcoimg release will incclude the new Package Installer, and will include core component installers for files and assemblies as well as package specific component installers for Authentication Systems and EditControls. Future Releases, will port the three major installers (Modules, Language Packs and Skins) and provide a unified Host/Admin UI.
I believe that this new Enhancement will provide a huge benefit for the Extensions EcoSystem as it will open up the possiblities for adding new extension points (and new revenue possiblities for developers and designers)