Usman ur Rehman Ahmed's blog

Dependency section of a DNN manifest file

Dependencies Section

The dependencies section was introduced in the DNN’s manifest file with the new installation mechanism. Intending to support true extensions based deployment philosophy in DNN where one package may contain various different types of components.

Dependencies as the name suggest provide a check and validation for installation to continue. Different types of validations can be performed identified by the type attribute value in the dependency section as following,

      <dependencies>

        <dependency type="Type|CoreVersion|Package|Permission"></dependency>

      </dependencies>

Note: A manifest file with no dependencies is defined as following,

      <dependencies />

The dependency is usually found at following location in the manifest file,

Dependency
type=Type

Type is used to represent a class. Please note that fully qualified name of the class must be supplied. In type you can specify any class from any other module. For example to ensure that user defined table module is installed,

      <dependencies>

        <dependency type="Type">DotNetNuke.Modules.UserDefinedTable.UserDefinedTableController</dependency>

      </dependencies>

type=CoreVersion

CoreVesion specifies the minimum core version of DNN that must be present for the package to be installed. For example below snippet ensures that this package can be installed on sites running on top of DNN’s 05.05.01 version or above,

      <dependencies>

        <dependency type="CoreVersion">05.05.00</dependency>

      </dependencies>

type=Package

A type of Package refers to the check on name (not the friendly name) of the package that must be installed prior to installation of this module. For example, a rule like this would mean,

      <dependencies>

        <dependency type="Package">SampleModule</dependency>

      </dependencies>

 

That a package “SampleModule” is already installed with manifest file as following,

<dotnetnuke type="Package" version="5.0">

  <packages>

    <package name="SampleModule" type="Module" version="01.00.07">

      <friendlyName>A sample Module</friendlyName>

type=Permission

Permission type refers to the ability to specify the core .NET permission set required for this module to be operational. In case of installations on shared web hosting this is a great feature to be utilized. For example the dependency below,

      <dependencies>

        <dependency type="Permission">System.Web.AspNetHostingPermission</dependency>

      </dependencies>

ensures that the trust level of the executing DNN website application is higher enough to access protected ASP .NET classes. Examples include the use of classes encapsulated within System.Diagnostic namespace while your site is running with minimal trust level on a shared hosting.

Thus if your code does utilize such a class, having a dependency rule like above will help you protect your module customer’s websites going down by restricting module installation while also prompting a message giving insight why the installation couldn’t be carried out.

Most important types of permissions are exposed under System.Security.Permissions namespace like,

-         EnvironmentPermission

-          SecurityPermissions

For more information of permissions please take a look at,

http://msdn.microsoft.com/en-us/library/system.security.permissions.aspx

Mixing Dependency Types

It is possible to mix different dependencies together to make up a strict validation rule to be met for installation to continue. This may be required in some cases. An example is to install a module that requires SSL powered DNN (which was in 5.4.0 I believe) and a custom module (FileTransferModule) be installed,

      <dependencies>

        <dependency type="CoreVersion">05.04.00</dependency>

        <dependency type="Package">FileTransferModule</dependency>

      </dependencies>

11
To Posterous, Love Metalab