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
- Creating DotNetNuke Modules - May 20th, 2008
- Creating DNN Modules - The Tools - May 22nd, 2008
- DotNetNuke Modules - Foundational Concepts - May 26th, 2008
- DotNetNuke Modules - Creating Base Modules - May 28th, 2008
- DotNetNuke Modules - Registering Your Module - May 29th, 2008
- DotNetNuke Modules - Where Stuff Shows Up - June 3rd, 2008
- DotNetNuke Modules - Anatomy of the View - June 9th, 2008
- DotNetNuke Modules - Adding Actions - June 11th, 2008
- DotNetNuke Modules - DNN Controls - Label - June 18th, 2008
- DotNetNuke - Internationalization - June 25th, 2008
- DotNetNuke Modules - Internationalization (part 2) - June 30th, 2008
- DotNetNuke Modules - Labels w/ no Help - July 9th, 2008
- DotNetNuke Modules - LinkButtons - July 14th, 2008
- DotNetNuke Modules - Collapsible Panels - July 16th, 2008
- DotNetNuke - The Data Layer - Installing CodeSmith - July 22nd, 2008
- DotNetNuke - Modules - Creating The Tables - July 24th, 2008
- DotNetNuke - Modules - Creating Stored Procs - July 29th, 2008
- DotNetNuke - Modules - Portal Specific Modules - July 31st, 2008
- DotNetNuke Modules - Data Access Layer - August 5th, 2008
- DotNetNuke Modules - Data Access Layer - August 7th, 2008
- DotNetNuke - Data Access Layer Alternative - August 12th, 2008
- DotNetNuke - Modules - Linking within the module - August 14th, 2008
- DotNetNuke - Make Your Module Searchable - August 19th, 2008
- DotNetNuke Modules - Making Content Portable - August 25th, 2008
- DotNetNuke Modules - Exceptions the DNN Way - September 2nd, 2008
- DotNetNuke Modules - PortalModuleBase - September 4th, 2008
- DotNetNuke Modules - Inter Module Communication - September 9th, 2008
- DotNetNuke Modules - Finding The Page a Module is On - September 15th, 2008
- DotNetNuke Modules - Caching - September 17th, 2008
- DotNetNuke Modules - Module Settings - September 22nd, 2008
- DotNetNuke Modules - Retrieving Settings - September 24th, 2008
- DotNetNuke Modules - Advanced Architecture - October 20th, 2008
- DotNetNuke Modules - Creating the PA - October 30th, 2008
- DotNetNuke Modules - Automating the PA - November 5th, 2008
- DotNetNuke - FileUploadControl Danger! - February 26th, 2009
- Changing an Existing DNN Module - March 4th, 2010
- Facebook App using DotNetNuke - January 19th, 2012
- DotNetNuke Modules - Install DNN into VS 2008 - June 19th, 2012
- DotNetNuke SecurityException AspnetHostingPermission - February 19th, 2013
- DotNetNuke Modules - Benefits of Architecture - April 9th, 2013
- Debugging TypeScript Under DotNetNuke - May 8th, 2013