DotNetNuke Modules – Creating the PA

IMG_1420 By now you have the basics for creating a DotNetNuke module.  The only question we have left to address is, how do we package this all up so that we can install it on another server?

The file we are going to create is called the Program Assembly (PA) and is a zip file that contains all the files that are needed for your module on the server and a file with a DNN extension that defines the module so that all the configuration options we put in DotNetNuke to define the module can be placed on the DotNetNuke installation we will install the PA into.

The first thing we want to take a look at is the DNN file.

When you created the module with the wizard, a file with the name of the module and the DNN extension was placed in the Module’s directory under the DesktopModules directory.  It should still be there.

Here is a copy of a DNN file from a project I have worked on in the past:

<dotnetnuke version="3.0" type="Module">
  <folders>
    <folder>
      <name>dmbcllc.SplitTester</name>
      <friendlyname>SplitTester</friendlyname>
      <foldername>dmbcllc.SplitTester</foldername>
      <modulename>dmbcllc.SplitTester</modulename>
      <description>A SplitTester module</description>
      <version>01.00.00</version>
      <businesscontrollerclass></businesscontrollerclass>
      <modules>
        <module>
          <friendlyname>SplitTester</friendlyname>
          <cachetime>60</cachetime>
          <controls>
            <control>
              <src>DesktopModules/SplitTester/ViewSplitTester.ascx</src>
              <type>View</type>
              <helpurl></helpurl>
            </control>
          </controls>
        </module>
      </modules>
      <files>
        <file>
          <name>ViewSplitTester.ascx</name>
        </file>
        <file>
          <name>ViewSplitTester.ascx.cs</name>
        </file>
        <file>
          <path>App_LocalResources</path>
          <name>ViewSplitTester.ascx.resx</name>
        </file>
        <file>
          <name>01.00.00.SqlDataProvider</name>
        </file>
        <file>
          <name>Uninstall.SqlDataProvider</name>
        </file>
      </files>
    </folder>
  </folders>
</dotnetnuke>

It’s actually a pretty simple file.

Starting from the top:  The folders element encloses the entire package.  You can have multiple folder elements within the folders element.  The name element is a name that DotNetNuke will reference the module by internally.  It should be unique.  Notice that I’ve prefixed mine with my domain name.  I’ve used this same naming convention for the foldername element and the modulename element since this will only have one module.

Within a folder you can have multiple modules.  If you do that you’ll want to give each modulename element a unique string.

The businesscontrollerclass element would be the fully qualified classname that holds the class that the ISearchable and IPortable interfaces have been applied to.  If you haven’t used that, just leave this blank.

Don’t forget to set the version number of the module.  As you upgrade from one version to another, this number will be used to determine which SQL files you need to run.

Next we come to the modules element and the enclosing elements.  These should look familiar from when we created the module in the DotNetNuke application.  You define the friendlyname, the name that will display in DotNetNuke when people want to insert the module on the page.  You’ll also define the controls that make up the module.  The view, edit, and settings are the common control types you will use here.

Next is the files section.  This lists all of the files that make up the module.  Within the files element are multiple file elements–one for each file you need to include to enable this module to run.  You’ll notice that within a file element is an optional path element.  If you have files that need to go in your app_code directory when they are installed you’ll want the path to be “[app_code]” otherwise the path reference will be the path relative to the module directory the module is being installed into.

You’ll also notice that you’ll want to reference all of the SqlDataProvider files.  You’ll want a different one for each version that is a script to get the installation from the previous version of the install to the current version of the install.  Remember that I said you want to include the current version number at the top in the version element? This is why.

Finally, you’ll want to include all of the files listed in this DNN file and this DNN file in a zip file.  All of the files should be at the root directory in the zip file.  That is, if you open the zip file you should not see any subdirectories in it.  Just the files.

Once you’ve done that, you have a PA that can be installed using the DotNetNuke module installation facility.

Of course, if you are planning on needing to install this module frequently, you are going to want to automate all of this.  That will be the subject of our next “DotNetNuke Modules” post.

 

Other post in DotNetNuke - Module Development

Related Post

Leave a Reply

Comment Policy:

  • You must verify your comment by responding to the automated email that is sent to your email address. Unverified comments will never show.Leave a good comment that adds to the conversation and I'll leave your link in.
  • Leave me pure spam and I'll delete it.
  • Leave a general comment and I'll remove the link but keep the comment.

Notify me of followup comments via e-mail

Bear