The DNN manifest is an XML file (e.g., MyDNNExtension.dnn) that indicates how specific files in the extension package must be processed during installation.Only the files specifically declared in the manifest would be installed. Files inside any zip file specified in
component type="ResourceFile" do not have to be listed individually. Nonexistent files mentioned in the manifest will cause an error message.The manifest file extension must be
.dnn. You can add the DNN version at the end; e.g.,
MyDNNExtension.dnn7.Save the manifest file in the base folder of your package and include it when zipping your package files.
- name must be unique. To ensure your package's uniqueness, add your company as the prefix.
type can be one of the following:
- version holds the version of your extension.
Each package represents a DNN extension. You can install multiple extensions using a single DNN manifest by creating a
package section for each extension inside the
packages tag.Packages are installed in the order they appear in the manifest.Only the information about the first package is displayed during installation. This includes the package name, description, owner, license, and release notes.
friendlyName and description
The friendlyName and description are displayed during installation and are used in the Host > Extensions page, which lists the extensions that are installed or are available for installation. The friendlyName can contain spaces and up to 250 characters; the description can hold up to 2000 characters.
Optional. The icon is displayed in the DNN Control Panel's dropdown list and in the Extensions page. The .png format is preferred. If not specified, the DNN default icon is used.
Optional, but encouraged. Information about the owner or creator of the extension.
license and releaseNotes
Optional, but encouraged. These text files are displayed during the installation. The user is prompted to accept or decline the license. The release notes is displayed during the installation. The actual text can also be embedded within the tag without the src attribute.
Optional. Default is
false. Set to
true if the extension is compatible with Microsoft Azure.
Dependencies can be any of these types (case-insensitive):
- coreVersion. Minimum DNN version required by the extension being installed. Example:
The name and minimum version of a package required by the extension being installed. The required package must already be listed in the core Packages table.
The name of a package required by the extension being installed. The required package must already be listed in the core Packages table
A type in .NET, in a DNN library, or a third-party library. Ensures that the installation can create an object of the specified type.
Tip: Fully qualify a type if it is not in the App_Code folder to avoid conflicts with similarly named types from multiple sources.
- Any custom dependency type included in the Dependency list. DNN can be extended by creating custom dependency types, which inherit from DotNetNuke.Services.Installer.Dependencies.DependencyBase and must be included in the Dependency list (Host > Lists).
Note: The custom dependency type must already be installed before it is used in another installation.
Some component types are applicable only to the package type of the same name; generic component types can be used with any package type.
||Specific component type
||Generic component types
- Assemblies to be installed in the main \bin folder of the installation. Assemblies are the compiled code portion of your extension. They can be your own assemblies or third-party assemblies that you ship with your extension.
- Authentication providers used by the extension, such as Facebook, Google, Twitter, and Microsoft Accounts. By default, DNN authenticates using its own database.
Cleanup. List of files that must be deleted during installation or upgrade of the package.You can list the files individually in the manifest.You can also list the files with their paths in a text file instead.
- Component type
Config to update configuration files during uninstall.
- Component type
Script for data provider scripts that must be uninstalled.
Config. Changes to do on the specified config file.For information on
node attributes, see Manifest: XML Merge.
Container. Containers to be installed.
DashboardControl. Controls that will appear as separate tabs in the DNN Dashboard (Host > Dashboard).
File. Files to be installed. By default, only files with allowed file extensions are installed; however, the host user can bypass this security check during installation. To view or modify the list of file extensions, go to your DNN installation and choose Host > Host Settings > Other Settings > Allowable File Extensions.
CoreLanguage. Language pack files required to localize the core DNN Platform for a specific culture. A core language pack can be installed during the DNN Platform installation or anytime after.
ExtensionLanguage. Language pack files required to localize a DNN extension for a specific culture.
Module. Only one component with
type="Module" is allowed within a
package section. To install a set of modules as a unit, create one
package section per module in the same manifest.
Provider. Extends the list of allowed file extensions. These additional file extensions apply only to the current installation and are not added to the global list of file extensions found in Host > Host Settings > Other Settings > Allowable File Extensions. The following file extensions can be allowed: .ashx, .aspx, .ascx, .vb, .cs, .resx, .css, .js, .resources, .config, .xml, .htc, .html, .htm, .text, .vbproj, .csproj, and .sln.
ResourceFile. Zip files to be expanded during installation. Can be used instead of
component type="File" to simplify the manifest for packages that contain many files.
Script. Database scripts that the extension needs. The following scripts are handled differently:
install.SqlDataProvider) is executed before all other scripts, if the package is being installed for the first time.
upgrade.SqlDataProvider) is executed after all regular scripts.
Skin. All files related to the theme. The installer needs to parse the main theme files at installation time to replace relative folder names; therefore, every ASCX, HTML, or CSS file must be declared as a
skinFile. Other files (i.e., images and scripts) can be packaged using component type
ResourceFile to simplify the complexity of the theme manifest
SkinObject. Custom theme objects.
URLProvider. Custom URL provider to be used with the Advanced URL Management System (AUM