Learn More





Azure Compatible Extension Check

Return to previous page

  • 4/7/2015



Azure Compatible Extension Check

Last updated 3 years ago



(Enter the content of this article below)


From DNN 7.1 onward, a new installer check has been added to help protect the integrity of websites on Azure and using the SQL Azure database.

It is well known that some SQL Server syntax and operations are not supported by SQL Azure. A major problem arises when an install fails for these types of errors, which can leave a DNN site in an unstable state, where a module is half-installed and may require manual removal of a failed installation.

To protect DNN installations from problems like this, a new verification step has been added to the DNN Extension Installer.

Installer Logic for Azure Compatibility Check

The logic is simple, and is run during the Extension Install Wizard:
  • If the DNN Installation is NOT running on SQL Azure as a database, it will install as normal
  • If the DNN Installation is running on SQL Azure as a database and the Extension is marked as Azure Compatible, it will install as normal.
  • If the DNN Installation is running on SQL Azure as a database and the Extension is either marked as not being Azure Compatible, or does not include any indication of Azure Compatibility, a warning will be shown to the user while installing, and will require them to verify that they wish to continue with the installation.

Note: The installer check relates only to using SQL Azure as a database.

Adding the Azure Compatible Element to a DNN Manifest File

NOTE: These instructions relate ONLY to DNN Manifest files in Version 5.0 format or later. Including the element in earlier versions of DNN Manifest files will have no effect. If you wish to mark a module as Azure Compatible and the module does not have a Version 5.0 or later manifest file, please create a Version 5.0 manifest file and add it to the module package. See Manifest Files for more information

The actual element to include in the manifest file is very simple:


This should be implemented as a child of the element.

An example:
        <package name="Your_Package_Name" type="Module" version="07.01.00">

<friendlyName>Your Package Name</friendlyName>
Your Package Description
<name>DotNetNuke Corporation</name>
<organization>DotNetNuke Corporation</organization>
<email>[email protected]</email>
<license src="License.txt"/>
<releaseNotes src="ReleaseNotes.txt" />
<dependency type="Permission">AspNetHostingPermission</dependency>
<dependency type="CoreVersion">07.00.00</dependency>

NOTE: It is very important that you only mark a module as Azure Compatible if it has been tested and verified as SQL Azure compatible, either by testing on a SQL Azure based website, or by using the Extension Verification System. Marking a module as compatible when it is not will frustrate community members, DNN customers and will result in a low-quality experience for everyone involved. Under no circumstances should an Extension be marked as Azure compatible if it has not been tested and verified 'with each new release'.

Backward Compatibility

The element will be ignored by DNN 6 and DNN 7.0.x installations. If you are packaging an Extension for use with DNN versions earlier than this, you can include a separate DNN6/7 specific manifest file in your package. This is achieved by creating a Manifest file specific for DNN 6/7 (which includes the element) and giving it an extension of .dnn6 and adding both an earlier manifest file (file extension : .dnn) and the .dnn6 file into the Extension Zip.

When DNN 6 or DNN 7 opens the Extension zip package upon install, it will first look for a .dnn6 file, and if found, read the relevant Extension information from there. DNN 4 installations will look for a .dnn extension, and DNN 5 installations will look for either a .dnn or a .dnn5 extension.

See Also:
Azure Compatibility for DNN Extensions
No sections defined
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?