New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact community@dnnsoftware.com.

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

DotNetNuke 4.5 Features: Module Configuration Enhancements

Mar 10

Comments (2), Permalink

This post covers these three issues:

Enhancement DNN-5219 Module Packager Name/Location
New Feature DNN-5232 Module Installer - Permissions and Dependencies
Bug Fix DNN-5230 Module Installer Cleanup Manifest

Module Packager Name/Location

In the past when you used the Create Module Package (Host / Module Definitions / (then select a module definition))

It put the .zip file from the root directory of the portal.

The system will now create the package in /Install/Module directory so that it can be immediately installed into the application.

Now when you go to Host / Module Definitions

You will see the module in the Available Modules list. You can simply check the box and click Install Selected Modules

In addition, the default filename for the package has been improved to include support for DotNetNuke file naming conventions (ie. ModuleName_Version#_Install.zip).

Permissions and Dependencies

In order to support the complex usage scenarios in the community in terms of different hosting environments and module features, two new items to Module Definitions have been added:

Permissions - Modules can now optionally specify a semi-colon delimited list of Permissions which their module requires (for example, indicate WebPermission if your module needs to make web service calls from DotNetNuke (you do not need to set this to make calls in to DotNetNuke)). Then during install, if the environment does not support a specific permission, a message will be displayed to the user and the module will not be installed.
Dependencies - Modules can now optionally specify a semi-colon delimited list of Dependencies which their module requires (for example, indicate System.Web.UI.ScriptManager if your module requires that the site have ASP.NET AJAX installed and enabled). Then during install, if the environment does not support a specific permission, a message will be displayed to the user and the module will not be installed.

For example, in the following module definition Adefwebserver.MyComponent is indicated as a dependency. This could be a shared assembly/class that the module will be expecting.

If Adefwebserver.MyComponent is not available the installer will not install the module and will show an error:

Module Installer Cleanup Manifest

Previously, the cleanup manifest for modules would only be processed if the module had a BusinessControllerClass specified. This has now been fixed.

Published: March 10, 2007
By: Michael Washington

Comments

Comment Form

Only registered users may post comments.

Products

Solutions

Resources

Partners

Community

About