The New Extension Installer Manifest – Part 4, The Assembly Component

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.