Today (March 18th, 2009) during the keynote at MIX 09, Scott Guthrie announced the release of version 2 of the Web Platform Installer (WPI) and the release of the new Web Application Gallery.

Bill Staples, the Program Manager responsible for the Web Application Gallery described it as an “App Store for the Web”.  I am pleased to say that DotNetNuke Community Edition is part of this initiative and that Bill Staples used DotNetNuke as his demonstration install during the keynote.

If you want to download and try DotNetNuke Community Edition you can install it from the Web Application Gallery by clicking the image below.

The Installation Experience

When you click on the install link, you will get a popup (in Firefox 3) that confirms which program you want to use to run the installer.  In my case I already have the Web Platform Installer on my machine.

The Installer will launch and you will get the following screen.

Clicking on Install will download the application (in the case of DotNetNuke it will download from Codeplex) and display the following screen, where you can provide an “Application Name” – the default is dotnetnuke.

The second page allows the user to configure the database.

Clicking continue will set up IIS and SQL Server.  You will then see the final screen, which lets you know that the install was successful.

Finally clicking the link will automatically launch the DotNetNuke Install Wizard to complete the installation of your DotNetNuke Application.

Scott Hanselman has blogged about the new installer, using Das Blog as the example.  He describes some of the technical details behind the installer.  In a future article I will describe the set up of the DotNetNuke package, which I created for this initiative.

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.

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.

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

   1:  <component type="Assembly">

   2:    <assemblies>

   3:      <assembly>

   4:        <path>bin\Providers</path>

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

   6:        <version>05.00.01</version>

   7:      </assembly>

   8:    </assemblies>

   9:  </component>

Most of the components which handle files inherit from the base File Component, and so the Assembly Component has a <path> element and a <file> element.  The element name for the collection is <assemblies> rather than <files> and the element name for a single assembly is <assembly> rather than <file>,  but in code the actual copying of the file is handled by the base FileInstaller.

While the <version> element is defined for the File Component it is not really used for standard files.  However the version element is important for assemblies.

Registering Assemblies

One of the problems with earlier versions of DotNetNuke is in handling assembly versioning.  Each module, when installed just extracts its assemblies and copies them to the /bin folder, regardless of whether an existing version of the assembly is already in use. 

This makes life difficult, if module developers use 3rd party libraries of any kind – either their own shared code or controls from commercial vendors.  For example, if Module A uses Assembly A version 1 (Assembly A1) and Module B uses Assembly A version 2 (Assembly A2), then if Module A is installed after Module B it could break Module B as the older version (A1) is installed over the version Module B expects (A2).

Conversely, on uninstall, Module A will remove the associated assembly, which will again break Module B.

This situation is solved in the new Installer, by using the <version> element and by using assembly referencing.

   1:  Protected Overrides Function InstallFile(ByVal file As InstallFile) As Boolean

   2:      Dim bSuccess As Boolean = True

   3:   

   4:      If file.Action = "UnRegister" Then

   5:          DeleteFile(file)

   6:      Else

   7:          'Attempt to register assembly this will return False if the assembly exists

   8:          'and true if it does not or is older

   9:          Dim returnCode As Integer = DataProvider.Instance.RegisterAssembly(Me.Package.PackageID, 

  10:                                                           file.Name, file.Version.ToString(3))

  11:          Select Case returnCode

  12:              Case 0

  13:                  'Assembly Does Not Exist

  14:                  Log.AddInfo(Util.ASSEMBLY_Added + " - " + file.FullName)

  15:              Case 1

  16:                  'Older version of Assembly Exists

  17:                  Log.AddInfo(Util.ASSEMBLY_Updated + " - " + file.FullName)

  18:              Case 2, 3

  19:                  'Assembly already Registered

  20:                  Log.AddInfo(Util.ASSEMBLY_Registered + " - " + file.FullName)

  21:          End Select

  22:   

  23:          'If assembly not registered, is newer (or is the same version and we are in repair mode)

  24:          If returnCode < 2 OrElse (returnCode = 2 AndAlso file.InstallerInfo.RepairInstall) Then

  25:              'Call base class version to copy file to \bin

  26:              bSuccess = MyBase.InstallFile(file)

  27:          End If

  28:      End If

  29:      Return bSuccess

  30:  End Function

The AssemblyInstaller overrides the InstallFile method of the base FileComponent (it also overrides the DeleteFile method – see later), and before copying the file into the /bin folder, it registers the assembly in the database (see Listing 2).  The RegisterAssembly method checks if the assembly is already registered by another extension and returns one of 4 return Codes.

• 0 – Assembly does not exist
• 1 – An older version of the assembly exists
• 2 – The same version of the assembly exists
• 3 – A newer version of the assembly exists

If the return code is 0 or 1 then the file is copied (as the assembly does not exist or is older than the current version) by calling the base FileInstaller class’s InstallFile method.  If the return code is 2 the assembly is only copied if we are repairing the install, and if the return code is 3 the assembly is not copied as it could potentially break another extension that is already installed.

The RegisterAssemby method adds an entry into the Assemblies table, recording the PackageID of the Extension which registered the assembly.

Figure 1 – The Assemblies Table

UnRegistering Assemblies

On uninstall the reverse process happens.  As mentioned above, the AssemblyInstaller also overrides the base FileInstaller’s DeleteFile method.

   1:  Protected Overrides Sub DeleteFile(ByVal file As InstallFile)

   2:      'Attempt to unregister assembly this will return False if the 

   3:      'assembly is used by another package and cannot be delete and

   4:      'true if it is not being used and can be deleted

   5:      If DataProvider.Instance.UnRegisterAssembly(Me.Package.PackageID, file.Name) Then

   6:          Log.AddInfo(Util.ASSEMBLY_UnRegistered + " - " + file.FullName)

   7:          'Call base class version to deleteFile file from \bin

   8:          MyBase.DeleteFile(file)

   9:      Else

  10:          Log.AddInfo(Util.ASSEMBLY_InUse + " - " + file.FullName)

  11:      End If

  12:  End Sub

In the DeleteFile method (see Listing 3), the UnRegisterAssembly method is called.  This method removes the record from the assemblies table and returns a boolean value:

• true – the registration was the only registration for this assembly and the assembly can be safely deleted
• false – there are other extensions which still require the assembly and the assembly should not be deleted

So the result of this is that, by using assembly counting, we can improve the situation where shared assemblies are being used.  The only remaining case which could break Extensions is if a shared assembly does not retain binary compatibility in newer versions.