Benvis Blog

The DNN Manifest Schema

Monday 05 July 2021

The DNN Manifest Schema

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.

Package type Specific component type Generic component types
Auth_System AuthenticationSystem







Container Container
CoreLanguagePack CoreLanguage
DashboardControl DashboardControl
ExtensionLanguagePack ExtensionLanguage
Module Module


URL Provider

Skin Skin
SkinObject SkinObject
  • 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 FacebookGoogleTwitter, 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.
  • See also:
    • 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.<dataprovidertype> (e.g., install.SqlDataProvider) is executed before all other scripts, if the package is being installed for the first time.
    • upgrade.<dataprovidertype> (e.g., 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

Benvis is a web application development service with over 20 employees located in Australia and Iran. Our main services include web design, web development, UX/UI design, and digital marketing.


Monday-Friday: 08:00 - 16:30 (GMT+11)

Sat-Sun: closed


    Copyright 2024 by Benvis
    • Back to top